建站
咨詢
售后
建站咨詢
新聞中心
作為一個(gè)架構(gòu)師，如果在面試的時(shí)候，面試官說出了一個(gè)英文縮寫，這個(gè)時(shí)候如果你沒有聽過，是不是很尷尬?而且你也沒辦法針對(duì)這個(gè)問題進(jìn)行描述回答!所以，多學(xué)習(xí)一些基礎(chǔ)的英文縮寫，一是面試可以游刃有余，二是可炫耀!下面的20個(gè)縮寫，你都能講清楚嗎?
創(chuàng)新互聯(lián)主要從事成都做網(wǎng)站、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)湖州,10多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220
IOC：
控制反轉(zhuǎn)(Inversion of Control，縮寫為IoC)，是面向?qū)ο缶幊讨械囊环N設(shè)計(jì)原則，可以用來減低計(jì)算機(jī)代碼之間的耦合度。其中最常見的方式叫做依賴注入(Dependency Injection，簡稱DI)，還有一種方式叫“依賴查找”(Dependency Lookup)。通過控制反轉(zhuǎn)，對(duì)象在被創(chuàng)建的時(shí)候，由一個(gè)調(diào)控系統(tǒng)內(nèi)所有對(duì)象的外界實(shí)體將其所依賴的對(duì)象的引用傳遞給它。也可以說，依賴被注入到對(duì)象中。
AOP：
在軟件業(yè)，AOP為Aspect Oriented Programming的縮寫，意為：面向切面編程，通過預(yù)編譯方式和運(yùn)行期動(dòng)態(tài)代理實(shí)現(xiàn)程序功能的統(tǒng)一維護(hù)的一種技術(shù)。AOP是OOP的延續(xù)，是軟件開發(fā)中的一個(gè)熱點(diǎn)，也是Spring框架中的一個(gè)重要內(nèi)容，是函數(shù)式編程的一種衍生范型。利用AOP可以對(duì)業(yè)務(wù)邏輯的各個(gè)部分進(jìn)行隔離，從而使得業(yè)務(wù)邏輯各部分之間的耦合度降低，提高程序的可重用性，同時(shí)提高了開發(fā)的效率。
CAS：
是一種樂觀鎖機(jī)制。CAS是英文單詞Compare And Swap的縮寫，翻譯過來就是比較并替換。CAS機(jī)制當(dāng)中使用了3個(gè)基本操作數(shù)：內(nèi)存地址V，舊的預(yù)期值A(chǔ)，要修改的新值B。更新一個(gè)變量的時(shí)候，只有當(dāng)變量的預(yù)期值A(chǔ)和內(nèi)存地址V當(dāng)中的實(shí)際值相同時(shí)，才會(huì)將內(nèi)存地址V對(duì)應(yīng)的值修改為B。
CAP：
CAP原則又稱CAP定理，指的是在一個(gè)分布式系統(tǒng)中，一致性(Consistency)、可用性(Availability)、分區(qū)容忍性(Partition tolerance)。CAP 原則指的是，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。
一致性(C)：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否同樣的值。(等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本)
可用性(A)：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請(qǐng)求。(對(duì)數(shù)據(jù)更新具備高可用性)
分區(qū)容忍性(P)：以實(shí)際效果而言，分區(qū)相當(dāng)于對(duì)通信的時(shí)限要求。系統(tǒng)如果不能在時(shí)限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。
AICD：
事務(wù)屬性AICD：
原子性(Atomicity)：整體不可分割性，要么全做要不全不做。
一致性(Consistency) ：事務(wù)執(zhí)行前、后數(shù)據(jù)庫狀態(tài)均一致。
隔離性(Isolation) ：在事務(wù)未提交前，它操作的數(shù)據(jù)，對(duì)其它用戶不可見(從其他session讀取的數(shù)據(jù)還是commit之前的數(shù)據(jù)狀態(tài))。
持久性(Durability)：一旦事務(wù)成功，將進(jìn)行永久的變更，記錄與redo日志。
RC：
數(shù)據(jù)庫隔離級(jí)別，Read Committed(讀取提交內(nèi)容)。
(1) 這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認(rèn)隔離級(jí)別(但不是MySQL默認(rèn)的)
(2)它滿足了隔離的簡單定義：一個(gè)事務(wù)只能看見已經(jīng)提交事務(wù)所做的改變
(3)這種隔離級(jí)別出現(xiàn)的問題是——不可重復(fù)讀(Nonrepeatable Read)：不可重復(fù)讀意味著我們?cè)谕粋€(gè)事務(wù)中執(zhí)行完全相同的select語句時(shí)可能看到不一樣的結(jié)果。
RR：
數(shù)據(jù)庫隔離級(jí)別，Repeatable Read(可重讀)。
(1)這是MySQL的默認(rèn)事務(wù)隔離級(jí)別。
(2)它確保同一事務(wù)的多個(gè)實(shí)例在并發(fā)讀取數(shù)據(jù)時(shí)，會(huì)看到同樣的數(shù)據(jù)行。
(3)此級(jí)別可能出現(xiàn)的問題——幻讀(Phantom Read)：當(dāng)用戶讀取某一范圍的數(shù)據(jù)行時(shí)，另一個(gè)事務(wù)又在該范圍內(nèi)插入了新行，當(dāng)用戶再讀取該范圍的數(shù)據(jù)行時(shí)，會(huì)發(fā)現(xiàn)有新的“幻影” 行。
(4)InnoDB和Falcon存儲(chǔ)引擎通過多版本并發(fā)控制(MVCC，Multiversion Concurrency Control)機(jī)制解決了該問題。
Binlog：
是The Binary Log的簡稱，意思就是二進(jìn)制的日志文件。binlog是一個(gè)二進(jìn)制格式的文件，用于記錄用戶對(duì)數(shù)據(jù)庫更新的SQL語句信息，例如更改數(shù)據(jù)庫表和更改內(nèi)容的SQL語句都會(huì)記錄到binlog里，但是對(duì)庫表等內(nèi)容的查詢不會(huì)記錄。默認(rèn)情況下，binlog日志是二進(jìn)制格式的，不能使用查看文本工具的命令(比如，cat，vi等)查看，而使用mysqlbinlog解析查看。當(dāng)有數(shù)據(jù)寫入到數(shù)據(jù)庫時(shí)，還會(huì)同時(shí)把更新的SQL語句寫入到對(duì)應(yīng)的binlog文件里，這個(gè)文件就是上文說的binlog文件。使用mysqldump備份時(shí)，只是對(duì)一段時(shí)間的數(shù)據(jù)進(jìn)行全備，但是如果備份后突然發(fā)現(xiàn)數(shù)據(jù)庫服務(wù)器故障，這個(gè)時(shí)候就要用到binlog的日志了。主要作用是用于數(shù)據(jù)庫的主從復(fù)制及數(shù)據(jù)的增量恢復(fù)。
MVCC：
Multi-Version Concurrency Control 多版本并發(fā)控制，MVCC 是一種并發(fā)控制的方法，一般在數(shù)據(jù)庫管理系統(tǒng)中，實(shí)現(xiàn)對(duì)數(shù)據(jù)庫的并發(fā)訪問;在編程語言中實(shí)現(xiàn)事務(wù)內(nèi)存。MVCC是通過保存數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)的快照來實(shí)現(xiàn)的. 不同存儲(chǔ)引擎的MVCC. 不同存儲(chǔ)引擎的MVCC實(shí)現(xiàn)是不同的,典型的有樂觀并發(fā)控制和悲觀并發(fā)控制。
RESP：
Redis Serialization Protocol，RESP 是 Redis 序列化協(xié)議的簡寫。它是一種直觀的文本協(xié)議，優(yōu)勢在于實(shí)現(xiàn)異常簡 單，解析性能極好。
COW：
寫入時(shí)復(fù)制(英語：Copy-on-write，簡稱COW)是一種計(jì)算機(jī)程序設(shè)計(jì)領(lǐng)域的優(yōu)化策略。其核心思想是，如果有多個(gè)調(diào)用者(callers)同時(shí)請(qǐng)求相同資源(如內(nèi)存或磁盤上的數(shù)據(jù)存儲(chǔ))，他們會(huì)共同獲取相同的指針指向相同的資源，直到某個(gè)調(diào)用者試圖修改資源的內(nèi)容時(shí)，系統(tǒng)才會(huì)真正復(fù)制一份專用副本(private copy)給該調(diào)用者，而其他調(diào)用者所見到的最初的資源仍然保持不變。這過程對(duì)其他的調(diào)用者都是透明的(transparently)。 優(yōu)點(diǎn)是如果調(diào)用者沒有修改該資源，就不會(huì)有副本(private copy)被建立，因此多個(gè)調(diào)用者只是讀取操作時(shí)可以共享同一份資源。
AMQP：
即Advanced Message Queuing Protocol,一個(gè)提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級(jí)消息隊(duì)列協(xié)議,是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn),為面向消息的中間件設(shè)計(jì)。基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同的開發(fā)語言等條件的限制。Erlang中的實(shí)現(xiàn)有 RabbitMQ等。
SDS：
簡單動(dòng)態(tài)字符串(simple dynamic string，SDS)的抽象類型。字符串是Redis中最為常見的數(shù)據(jù)存儲(chǔ)類型，其底層實(shí)現(xiàn)是簡單動(dòng)態(tài)字符串sds(simple dynamic string)，是可以修改的字符串。它類似于Java中的ArrayList，它采用預(yù)分配冗余空間的方式來減少內(nèi)存的頻繁分配。C語言字符串使用長度為n+1的字符數(shù)組來表示長度為n的字符串，并且字符數(shù)組的最后一個(gè)元素總是空字符'\0'，因?yàn)檫@種字符串表示方式不能滿足Redis對(duì)字符串在安全性、效率以及功能方面的要求，所以Redis自己構(gòu)建了SDS，用于滿足其需求。在Redis里，C語言字符串只用于一些無須對(duì)字符串值進(jìn)行修改的地方，比如：日志。在Redis中，包含字符串值的鍵值對(duì)都是使用SDS實(shí)現(xiàn)的，除此之外，SDS還被用于AOF緩沖區(qū)、客戶端狀態(tài)的輸入緩沖區(qū)。
DDD：
DDD(Domain-Driven Design 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))是由Eric Evans最先提出，目的是對(duì)軟件所涉及到的領(lǐng)域進(jìn)行建模，以應(yīng)對(duì)系統(tǒng)規(guī)模過大時(shí)引起的軟件復(fù)雜性的問題。整個(gè)過程大概是這樣的，開發(fā)團(tuán)隊(duì)和領(lǐng)域?qū)＜乙黄鹜ㄟ^ 通用語言(Ubiquitous Language)去理解和消化領(lǐng)域知識(shí)，從領(lǐng)域知識(shí)中提取和劃分為一個(gè)一個(gè)的子領(lǐng)域(核心子域，通用子域，支撐子域)，并在子領(lǐng)域上建立模型，再重復(fù)以上步驟，這樣周而復(fù)始，構(gòu)建出一套符合當(dāng)前領(lǐng)域的模型。
RDB：
Redis支持RDB和AOF兩種持久化機(jī)制，持久化功能有效地避免因進(jìn)程退出造成的數(shù)據(jù)丟失問題，當(dāng)下次重啟時(shí)利用之前持久化文件即可實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。RDB (Redis DataBase)。RDB 是 Redis 默認(rèn)的持久化方案。在指定的時(shí)間間隔內(nèi)，執(zhí)行指定次數(shù)的寫操作，則會(huì)將內(nèi)存中的數(shù)據(jù)寫入到磁盤中。即在指定目錄下生成一個(gè)dump.rdb文件。Redis 重啟會(huì)通過加載dump.rdb文件恢復(fù)數(shù)據(jù)。RDB持久化是把當(dāng)前進(jìn)程數(shù)據(jù)生成快照保存到硬盤的過程，觸發(fā)RDB持久化過程分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)。
AOF：
Redis支持RDB和AOF兩種持久化機(jī)制，持久化功能有效地避免因進(jìn)程退出造成的數(shù)據(jù)丟失問題，當(dāng)下次重啟時(shí)利用之前持久化文件即可實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。AOF(append only file)持久化：以獨(dú)立日志的方式記錄每次寫命令，重啟時(shí)再重新執(zhí)行AOF文件中命令達(dá)到恢復(fù)數(shù)據(jù)的目的。AOF的主要作用是解決了數(shù)據(jù)持久化的實(shí)時(shí)性，目前已經(jīng)是Redis持久化的主流方式。
ZAB：
ZAB 協(xié)議全稱：Zookeeper Atomic Broadcast(Zookeeper 原子廣播協(xié)議)。ZAB 協(xié)議的消息廣播過程使用的是一個(gè)原子廣播協(xié)議，類似一個(gè) 二階段提交過程。對(duì)于客戶端發(fā)送的寫請(qǐng)求，全部由 Leader 接收，Leader 將請(qǐng)求封裝成一個(gè)事務(wù) Proposal，將其發(fā)送給所有 Follwer ，然后，根據(jù)所有 Follwer 的反饋，如果超過半數(shù)成功響應(yīng)，則執(zhí)行 commit 操作(先提交自己，再發(fā)送 commit 給所有 Follwer)。
ACK：
ACK消息，Acknowledgement 。是在計(jì)算機(jī)網(wǎng)上中通信協(xié)議的一部分，是設(shè)備或是進(jìn)程發(fā)出的消息，回復(fù)已收到數(shù)據(jù)。例如在傳輸控制協(xié)議(TCP，Transmission Control Protocol)中就有用ACK來告知?jiǎng)?chuàng)建鏈接時(shí)有收到SYN數(shù)據(jù)包、使用鏈接時(shí)有收到數(shù)據(jù)包，或是在中止鏈接有收到FIN數(shù)據(jù)包。
BIO：
Blocking Input Output，同步阻塞I/O模式，數(shù)據(jù)的讀取寫入必須阻塞在一個(gè)線程內(nèi)等待其完成。服務(wù)器實(shí)現(xiàn)模式為一個(gè)連接一個(gè)線程，即客戶端有連接請(qǐng)求時(shí)服務(wù)器端就需要啟動(dòng)一個(gè)線程進(jìn)行處理，如果這個(gè)連接不做任何事情會(huì)造成不必要的線程開銷，當(dāng)然可以通過線程池機(jī)制改善。
NIO：
NIO是指將IO模式設(shè)為“Non-Blocking”模式。NIO是一種同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，對(duì)應(yīng) java.nio 包，提供了 Channel , Selector，Buffer等抽象。NIO中的N可以理解為Non-blocking，不單純是New。它支持面向緩沖的，基于通道的I/O操作方法。
名稱欄目：架構(gòu)師必備的20個(gè)英文縮寫！看你知道幾個(gè)？
分享鏈接：http://www.5511xx.com/article/ccegpii.html
