a. 暫存埋點資料，後續用於統計分析
b. 解耦上下游系統
c. 實現乙個分布式鎖
d. 實現乙個分布式的任務排程系統
答案：ab
解析：訊息佇列最常被使用的三種場景：非同步處理、流量控制（削峰填谷）和服務解耦。答案 a 中描述的問題，使用訊息佇列解決，符合非同步處理和流量控制這兩種場景。選項 b，顯而易見也是正確的。c、d 選項提到的實現分布式鎖和分布式的任務排程系統，並不是訊息佇列擅長解決的。
a. kafka
b. rocketmq
c. rabbitmq
d. 以上都不能
答案：d
解析：關於訊息可靠性的服務水平，有下面三種級別：
kafka、rocketmq 和 rabbitmq 以及我們常見的大部分訊息佇列，能提供的服務水平都是一樣的：at least once，也就是至少一次，訊息有可能會重複，但可以保證不丟訊息。
這裡面比較容易出錯的是 kafka，因為 kafka 宣稱是支援 exactly once 特性的，但是，kafka 支援的這個「exactly once」特性，並不是保證我們這個題目中所說的「從訊息生產直到消費完成」這一過程中訊息不重不丟。它解決的是，在流計算中，用 kafka 作為資料來源，並且將計算結果儲存到 kafka 這種場景下，資料從 kafka 的某個主題中消費，在計算集群中計算，再把計算結果儲存在 kafka 的其他主題中。這樣乙個過程中，kafka 的 exactly once 機制，保證每條訊息都被恰好計算一次，確保計算結果正確。
a. 檢索表演算法：在檢索表中儲存 key 和分割槽的對應關係，通過查表確定分割槽號。
b. 取模演算法：分割槽號 = key mod 分割槽總數
c. 一致性雜湊演算法
d. 輪詢演算法
答案：ac
解析：大部分訊息佇列都只能保證在分割槽（佇列）上的嚴格順序，所以，對於這道題目，我們選擇的分片演算法必須保證具有相同 key 的訊息，都分到同乙個分割槽上。對於這個要求，答案 abc 都能做到，所以答案 d 先淘汰掉。
然後我們再看，擴容的時候怎麼來保證嚴格順序呢？那就是要選擇具備單調性的分片演算法，單調性是指如果已經有一些內容通過雜湊分派到了相應的分割槽中，又有新的分割槽加入到主題中，雜湊的結果應能夠保證，原有已分配的內容可以被對映到原有的或者新的分割槽中去，而不會被對映到舊的分割槽集合中的其他分割槽。只要是滿足單調性的分片演算法，我們就可以按照「先擴容分割槽 -> 將舊分割槽中的遺留訊息消費完 -> 同時消費所有分割槽」這樣乙個方式，確保擴容過程中訊息的嚴格順序。
選項 c 中的一致性雜湊演算法是滿足單調性的，這個沒有問題。選項 a 中的檢索表法，由於這個表中對映關係是可以手工配置的，那我們可以把這個對映關係配置成滿足單調性，所以選項 a 也是正確的。選項 b 中的取模演算法不符合單調性原則，所以這道題的答案是 ac。
a. 同乙個主題的多個消費組之間是競爭消費
b. 同乙個消費組的多個消費者之間是競爭消費
c. 每個消費組都會消費主題的乙份全量訊息
d. 每個消費者都會消費主題的乙份全量訊息
答案：bc
解析：這是乙個關於消費模型概念的問題。每個消費組就是乙份訂閱，它要消費主題的所有分割槽（佇列）的全部訊息。注意，佇列裡的訊息並不是消費掉就沒有了，這裡的消費只是去佇列裡面讀了訊息，並沒有刪除，消費完這條訊息還是在佇列裡面。所以，其他的消費組依然可以消費到同樣的訊息。
然後我們再說消費組的內部，乙個消費組中可以包含多個消費者的例項，同乙個消費組內這些消費之間是競爭消費，他們共同消費乙份主題的全量訊息。
a. 在執行轉賬操作時，在資料庫中更新賬戶餘額同時傳送事務訊息，非同步記錄轉賬流水。
b. 在支付系統中，完成賬戶餘額變更的同時傳送事務訊息，非同步通知支付發起方。
c. 在同乙個事務中傳送多條訊息，確保這些訊息要麼都傳送成功，要麼都傳送失敗。
d. 配合流計算平台，確保資料在流計算過程中不重不丟。
答案：b
解析：選項 a 描述的場景，因為它需要保證流水和餘額嚴格一致，所以並不適合用事務訊息來解決。即使非要用事務訊息來解決，也應該先在資料庫事務中記錄流水，再非同步更新餘額。這樣，即使出現資料不一致的問題，也可以用流水來更正餘額，反過來，我們是沒有辦法通過餘額反推出流水記錄的。
選項 b 是 rocketmq 事務訊息適用的典型場景，選項 c、d 是 kafka 事務適用的典型場景，也不適合用 rocketmq 的事務訊息來解決。所以，這道題的答案是 b。
a. 在集群模式下，將 broker 配置為非同步刷盤以提公升 broker 的寫入效能。
b. 為了保證 kafka 的 producer 在任何情況下都不丟訊息，需要把引數 acks 設定為 all，並將每次發訊息的批量大小 batch.size 設定為 1。
c. 如果不需要嚴格順序，為了提公升消費效能，可以將 consumer 設定為自動確認消費位置，然後批量拉取訊息放到記憶體佇列中，然後非同步多執行緒並行執行消費業務邏輯。
d. 在採用主從模式的 rocketmq 集群中，建立主題時為了保證主題的可用性，必須把主題中的佇列分布到多個 broker 上。
答案：bc
解析：選項 a，配置為非同步刷盤確實可以提公升訊息佇列的效能，這個是沒問題的。由於是在集群模式下，即使節點故障，記憶體中的資料還沒來得及刷盤也不會丟訊息，因為在集群模式下，訊息的可靠性是靠複製來保證的，我們仍然可以從其他節點上讀到故障節點丟失的那部分訊息，所以這個做法是沒問題的。
選項 b，kafka 傳送訊息的可靠性依靠的是「請求 - 確認」機制，即使是批量傳送，這個機制依然可以保證不丟訊息，所以沒必要把批量大小設定為 1，這個做法是錯誤的。
選項 c，是我們在課程中提到過的典型的錯誤做法，因為，這種「先確認消費位置再執行消費業務邏輯「的做法，訊息佇列就沒有辦法保證消費過程中不丟訊息，一旦消費節點宕機，記憶體中未處理的訊息就丟了。這個做法也是錯誤的。
選項 d，由於 rocketmq 的主從模式集群時不支援自動選舉的，一旦主節點宕機，雖然，消費者可以自動切換到從節點繼續消費，但生產者就不能再往這個節點上的佇列發訊息了。所以，為了保證生產的可用性，必須把主題中的佇列分布到多個 broker 上。這個做法也是沒問題的。
a. f(n, a)：給賬戶 n 轉入 a 元。
b. f(n, a)：將賬戶 n 的餘額更新為 a 元。
c. f(n, b, a)：如果賬戶 n 當前的餘額為 b 元，那就將賬戶的餘額更新為 a 元。
d. f(n, v, a)：如果賬戶 n 當前的流水號等於 v，那麼給賬戶的餘額加 a 元，並將流水號加 1。
答案：d
解析：選項a顯然不對。
選項b在併發下無法控制呼叫的先後順序，比如兩次呼叫 f(n,100)，f(n,200)，結果可能是100也可能是200。
選項 c 在併發下有可能出現 aba 問題：比如：賬戶餘額是 100 元，先轉入 100 元，再轉出 100 元，最終賬戶餘額還應該是 100 元。可能會出現這兩次操作實際上都執行成功了，這時候賬戶餘額是 100 元，但是第一次操作的響應在網路傳輸過程中丟失了，請求方執行了重試，這時，再次執行第一次操作，也就是「如果賬戶餘額是 100 元，那就更新為 200 元」，正好是可以執行成功的，這時候賬戶餘額被錯誤地更新成了 200 元。
a. 在 mysql 事務中，同步變更資料庫和 redis 中的賬戶餘額。
b. 訂閱 mysql 的 binlog，非同步更新 redis 中賬戶餘額。
c. 使用 rocketmq 的事務訊息，在本地事務中更新 mysql 中賬戶餘額，非同步更新 redis 中的賬戶餘額。
d. 將轉賬請求傳送到訊息佇列中，非同步並行更新 mysql 和 redis 中的賬戶餘額。
答案：a
解析：對於賬戶管理系統，如果要使用快取，它需要保證快取和資料庫中資料的嚴格一致性。轉賬成功後，查詢餘額卻沒有變化，這肯定是不能接受的。所以，必須用事務來保證快取和資料庫同步更新。這道題的答案是 a。
a. protobuf
b. json
c. 專用的二進位制序列化
d. 以上都可以
答案：b
解析：這個介面，它的特點是：資料量不大，對效能要求不高，介面資料複雜，接入方眾多。針對這種情況，應該選擇 json 這種視覺化的序列化方式，便於介面除錯。所以這道題的答案是 b。
a. kill [pid]
b. kill -9 [pid]
c. shutdown now
d. 拔掉伺服器電源線
答案：d
解析：對於這道題，首先需要明白：pagecache 是由作業系統來維護的，而不是使用 pagecache 的應用程式。作業系統可以保證，即使是應用程式意外退出了，作業系統也會把這部分資料同步到磁碟上。作業系統在正常關機過程中，也會保證把 pagecache 中的髒頁同步到磁碟中。所以，只有選項 d 這種情況，是有可能丟失資料的。
js基礎測試題學習筆記20170305
課堂筆記練習 1.有乙個名為 arr 的陣列中，存放著 1,2,3,4,5,6,7,8,9 請將該陣列中第乙個是 3 的倍數的數字列印到 控制台中 2.在頁面中列印向上的直角三角形,3.有兩個陣列 var array1 a b c e 和 var array2 d e f f 請把 array1 和...
訊息佇列學習筆記（一）
訊息佇列最常被使用的三種場景 非同步處理 流量控制和服務解耦。訊息佇列的適用範圍不僅僅侷限於這些場景，還有包括 作為發布 訂閱系統實現乙個微服務級系統間的觀察者模式 連線流計算任務和資料 用於將訊息廣播給大量接收者。簡單的說，我們在單體應用裡面需要用佇列解決的問題，在分布式系統中大多都可以用訊息佇列...
Kafka學習筆記（一） 訊息佇列
二 訊息佇列的應用場景 三 訊息佇列的缺點 四 訊息佇列的兩種模式 訊息 message 是指在應用之間傳送的資料，訊息可以非常簡單，比如只包含文字字串，也可以更複雜，可能包含嵌入物件。訊息佇列 message queue 是一種應用間的通訊方式，訊息傳送後可以立即返回，有訊息系統來確保資訊的可靠專...