架構師必備的20個英文縮寫！看你知道幾個？今天西安達內小編就針對架構師方面的知識點給大家分析一下！

作為一個架構師，如果在面試的時候，面試官說出了一個英文縮寫，這個時候如果你沒有聽過，是不是很尷尬?而且你也沒辦法針對這個問題進行描述回答!所以，多學習一些基礎的英文縮寫，一是面試可以游刃有余，二是可以裝逼!下面的20個縮寫，你都能講清楚嗎?

IOC：

控制反轉(Inversion of Control，縮寫為IoC)，是面向對象編程中的一種設計原則，可以用來減低計算機代碼之間的耦合度。其中最常見的方式叫做依賴注入(Dependency Injection，簡稱DI)，還有一種方式叫“依賴查找”(Dependency Lookup)。通過控制反轉，對象在被創(chuàng)建的時候，由一個調控系統(tǒng)內所有對象的外界實體將其所依賴的對象的引用傳遞給它。也可以說，依賴被注入到對象中。

AOP：

在軟件業(yè)，AOP為Aspect Oriented Programming的縮寫，意為：面向切面編程，通過預編譯方式和運行期動態(tài)代理實現(xiàn)程序功能的統(tǒng)一維護的一種技術。AOP是OOP的延續(xù)，是軟件開發(fā)中的一個熱點，也是Spring框架中的一個重要內容，是函數(shù)式編程的一種衍生范型。利用AOP可以對業(yè)務邏輯的各個部分進行隔離，從而使得業(yè)務邏輯各部分之間的耦合度降低，提高程序的可重用性，同時提高了開發(fā)的效率。

CAS：

是一種樂觀鎖機制。CAS是英文單詞Compare And Swap的縮寫，翻譯過來就是比較并替換。CAS機制當中使用了3個基本操作數(shù)：內存地址V，舊的預期值A，要修改的新值B。更新一個變量的時候，只有當變量的預期值A和內存地址V當中的實際值相同時，才會將內存地址V對應的值修改為B。

CAP：

CAP原則又稱CAP定理，指的是在一個分布式系統(tǒng)中，一致性(Consistency)、可用性(Availability)、分區(qū)容忍性(Partition tolerance)。CAP 原則指的是，這三個要素最多只能同時實現(xiàn)兩點，不可能三者兼顧。

一致性(C)：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。(等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本)

可用性(A)：在集群中一部分節(jié)點故障后，集群整體是否還能響應客戶端的讀寫請求。(對數(shù)據(jù)更新具備高可用性)

分區(qū)容忍性(P)：以實際效果而言，分區(qū)相當于對通信的時限要求。系統(tǒng)如果不能在時限內達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇。

AICD：

事務屬性AICD：

原子性(Atomicity)：整體不可分割性，要么全做要不全不做。

一致性(Consistency) ：事務執(zhí)行前、后數(shù)據(jù)庫狀態(tài)均一致。

隔離性(Isolation) ：在事務未提交前，它操作的數(shù)據(jù)，對其它用戶不可見(從其他session讀取的數(shù)據(jù)還是commit之前的數(shù)據(jù)狀態(tài))。

持久性(Durability)：一旦事務成功，將進行永久的變更，記錄與redo日志。

RC：

數(shù)據(jù)庫隔離級別，Read Committed(讀取提交內容)。

(1) 這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認隔離級別(但不是MySQL默認的)

(2)它滿足了隔離的簡單定義：一個事務只能看見已經(jīng)提交事務所做的改變

(3)這種隔離級別出現(xiàn)的問題是——不可重復讀(Nonrepeatable Read)：不可重復讀意味著我們在同一個事務中執(zhí)行完全相同的select語句時可能看到不一樣的結果。

RR：

數(shù)據(jù)庫隔離級別，Repeatable Read(可重讀)。

(1)這是MySQL的默認事務隔離級別。

(2)它確保同一事務的多個實例在并發(fā)讀取數(shù)據(jù)時，會看到同樣的數(shù)據(jù)行。

(3)此級別可能出現(xiàn)的問題——幻讀(Phantom Read)：當用戶讀取某一范圍的數(shù)據(jù)行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的數(shù)據(jù)行時，會發(fā)現(xiàn)有新的“幻影” 行。

(4)InnoDB和Falcon存儲引擎通過多版本并發(fā)控制(MVCC，Multiversion Concurrency Control)機制解決了該問題。

Binlog：

是The Binary Log的簡稱，意思就是二進制的日志文件。binlog是一個二進制格式的文件，用于記錄用戶對數(shù)據(jù)庫更新的SQL語句信息，例如更改數(shù)據(jù)庫表和更改內容的SQL語句都會記錄到binlog里，但是對庫表等內容的查詢不會記錄。默認情況下，binlog日志是二進制格式的，不能使用查看文本工具的命令(比如，cat，vi等)查看，而使用mysqlbinlog解析查看。當有數(shù)據(jù)寫入到數(shù)據(jù)庫時，還會同時把更新的SQL語句寫入到對應的binlog文件里，這個文件就是上文說的binlog文件。使用mysqldump備份時，只是對一段時間的數(shù)據(jù)進行全備，但是如果備份后突然發(fā)現(xiàn)數(shù)據(jù)庫服務器故障，這個時候就要用到binlog的日志了。主要作用是用于數(shù)據(jù)庫的主從復制及數(shù)據(jù)的增量恢復。

MVCC：

Multi-Version Concurrency Control 多版本并發(fā)控制，MVCC 是一種并發(fā)控制的方法，一般在數(shù)據(jù)庫管理系統(tǒng)中，實現(xiàn)對數(shù)據(jù)庫的并發(fā)訪問;在編程語言中實現(xiàn)事務內存。MVCC是通過保存數(shù)據(jù)在某個時間點的快照來實現(xiàn)的. 不同存儲引擎的MVCC. 不同存儲引擎的MVCC實現(xiàn)是不同的,典型的有樂觀并發(fā)控制和悲觀并發(fā)控制。

RESP：

Redis Serialization Protocol，RESP 是 Redis 序列化協(xié)議的簡寫。它是一種直觀的文本協(xié)議，優(yōu)勢在于實現(xiàn)異常簡 單，解析性能極好。

COW：

寫入時復制(英語：Copy-on-write，簡稱COW)是一種計算機程序設計領域的優(yōu)化策略。其核心思想是，如果有多個調用者(callers)同時請求相同資源(如內存或磁盤上的數(shù)據(jù)存儲)，他們會共同獲取相同的指針指向相同的資源，直到某個調用者試圖修改資源的內容時，系統(tǒng)才會真正復制一份專用副本(private copy)給該調用者，而其他調用者所見到的最初的資源仍然保持不變。這過程對其他的調用者都是透明的(transparently)。 優(yōu)點是如果調用者沒有修改該資源，就不會有副本(private copy)被建立，因此多個調用者只是讀取操作時可以共享同一份資源。

AMQP：

即Advanced Message Queuing Protocol,一個提供統(tǒng)一消息服務的應用層標準高級消息隊列協(xié)議,是應用層協(xié)議的一個開放標準,為面向消息的中間件設計。基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同的開發(fā)語言等條件的限制。Erlang中的實現(xiàn)有 RabbitMQ等。

SDS：

簡單動態(tài)字符串(simple dynamic string，SDS)的抽象類型。字符串是Redis中最為常見的數(shù)據(jù)存儲類型，其底層實現(xiàn)是簡單動態(tài)字符串sds(simple dynamic string)，是可以修改的字符串。它類似于Java中的ArrayList，它采用預分配冗余空間的方式來減少內存的頻繁分配。C語言字符串使用長度為n+1的字符數(shù)組來表示長度為n的字符串，并且字符數(shù)組的最后一個元素總是空字符'\0'，因為這種字符串表示方式不能滿足Redis對字符串在安全性、效率以及功能方面的要求，所以Redis自己構建了SDS，用于滿足其需求。在Redis里，C語言字符串只用于一些無須對字符串值進行修改的地方，比如：日志。在Redis中，包含字符串值的鍵值對都是使用SDS實現(xiàn)的，除此之外，SDS還被用于AOF緩沖區(qū)、客戶端狀態(tài)的輸入緩沖區(qū)。

DDD：

DDD(Domain-Driven Design 領域驅動設計)是由Eric Evans最先提出，目的是對軟件所涉及到的領域進行建模，以應對系統(tǒng)規(guī)模過大時引起的軟件復雜性的問題。整個過程大概是這樣的，開發(fā)團隊和領域專家一起通過 通用語言(Ubiquitous Language)去理解和消化領域知識，從領域知識中提取和劃分為一個一個的子領域(核心子域，通用子域，支撐子域)，并在子領域上建立模型，再重復以上步驟，這樣周而復始，構建出一套符合當前領域的模型。

RDB：

Redis支持RDB和AOF兩種持久化機制，持久化功能有效地避免因進程退出造成的數(shù)據(jù)丟失問題，當下次重啟時利用之前持久化文件即可實現(xiàn)數(shù)據(jù)恢復。RDB (Redis DataBase)。RDB 是 Redis 默認的持久化方案。在指定的時間間隔內，執(zhí)行指定次數(shù)的寫操作，則會將內存中的數(shù)據(jù)寫入到磁盤中。即在指定目錄下生成一個dump.rdb文件。Redis 重啟會通過加載dump.rdb文件恢復數(shù)據(jù)。RDB持久化是把當前進程數(shù)據(jù)生成快照保存到硬盤的過程，觸發(fā)RDB持久化過程分為手動觸發(fā)和自動觸發(fā)。

AOF：

Redis支持RDB和AOF兩種持久化機制，持久化功能有效地避免因進程退出造成的數(shù)據(jù)丟失問題，當下次重啟時利用之前持久化文件即可實現(xiàn)數(shù)據(jù)恢復。AOF(append only file)持久化：以獨立日志的方式記錄每次寫命令，重啟時再重新執(zhí)行AOF文件中命令達到恢復數(shù)據(jù)的目的。AOF的主要作用是解決了數(shù)據(jù)持久化的實時性，目前已經(jīng)是Redis持久化的主流方式。

ZAB：

ZAB 協(xié)議全稱：Zookeeper Atomic Broadcast(Zookeeper 原子廣播協(xié)議)。ZAB 協(xié)議的消息廣播過程使用的是一個原子廣播協(xié)議，類似一個 二階段提交過程。對于客戶端發(fā)送的寫請求，全部由 Leader 接收，Leader 將請求封裝成一個事務 Proposal，將其發(fā)送給所有 Follwer ，然后，根據(jù)所有 Follwer 的反饋，如果超過半數(shù)成功響應，則執(zhí)行 commit 操作(先提交自己，再發(fā)送 commit 給所有 Follwer)。

ACK：

ACK消息，Acknowledgement 。是在計算機網(wǎng)上中通信協(xié)議的一部分，是設備或是進程發(fā)出的消息，回復已收到數(shù)據(jù)。例如在傳輸控制協(xié)議(TCP，Transmission Control Protocol)中就有用ACK來告知創(chuàng)建鏈接時有收到SYN數(shù)據(jù)包、使用鏈接時有收到數(shù)據(jù)包，或是在中止鏈接有收到FIN數(shù)據(jù)包。

BIO：

Blocking Input Output，同步阻塞I/O模式，數(shù)據(jù)的讀取寫入必須阻塞在一個線程內等待其完成。服務器實現(xiàn)模式為一個連接一個線程，即客戶端有連接請求時服務器端就需要啟動一個線程進行處理，如果這個連接不做任何事情會造成不必要的線程開銷，當然可以通過線程池機制改善。

NIO：

NIO是指將IO模式設為“Non-Blocking”模式。NIO是一種同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，對應 java.nio 包，提供了 Channel , Selector，Buffer等抽象。NIO中的N可以理解為Non-blocking，不單純是New。它支持面向緩沖的，基于通道的I/O操作方法。