總結自：中華石衫
如何保證訊息佇列的高可用啊？
缺點：
* 導致系統可用性降低
就kafka來說：
* ha機制，就是replica副本機制
* isr
* leader 掛了咋辦？ broker掛了咋辦？ controller掛了咋辦？
* 原因 ：任務重啟，offset提交有間隔，導致部分資料被重複消費
* 措施 ：訊息佇列不保證重複資料，所以要開發一套 冪等性 機制
* 如果 是 redis，不用考慮，因為 redis 天然冪等性
* 業務上 每條資料 都生成唯一的id，每次處理資料的時候去快取（記憶體、redis）中查，看有沒有處理過
* 生產者弄丟了資料
ack=all，一定不會丟
* kafka 服務端丟資料（crash）
kafka的leader機器宕機了，將follower切換為leader之後，發現資料丟了
下面四個引數必須保證：
kafka服務端 replication.factor ：這個值必須大於1，要求每個partition必須有至少2個副本
kafka服務端 min.insync.replicas ：這個值必須大於1，這個是要求乙個leader至少感知到有至少乙個follower還跟自己保持聯絡，沒掉隊，這樣才能確保leader掛了還有乙個follower
producer端 acks=all：這個是要求每條資料，必須是寫入所有replica之後，才能認為是寫成功了
producer端 retries=max：這個是要求一旦寫入失敗，就無限重試，卡在這裡了
* 消費端弄丟了資料
原因：kafka只有一種可能：offset自動提交，但是處理資料的時候consumer掛了，那訊息就丟了
解決：關閉 kafka offset 自動提交，在處理完資料的時候提交。針對此時 consumer 掛了會出現重複消費的情況，用冪等性保證
* partition 裡的資料肯定有序，kafka 不保證 多個 partition 裡資料的有序性
* partition - consumer 一一對應，如果 kafka consumer 單執行緒 消費 + 處理，可能會影響 消費速度
* 當 consumer 只負責 取資料，取完資料丟 queue 裡面，處理執行緒從 queue 裡面取資料處理，可加快速度（queue可以有多個，queue - 處理執行緒 一一對應）
* 此時 要將 需要 有序的資料，放在 同乙個queue 裡面
-- 臨時緊急擴容-- ttl 盡量不要設
-- 手動寫程式，補資料
-- 消費到的資料就扔，達到快速消費目的
-- 消費到的資料就存（資料遷移系統），後期補資料
關鍵點：
* 基本功能
生產者消費者，維護佇列
* 支援伸縮性：在需要的時候進行擴容
參照 kafka 分布式系統，broker -> topic -> partition，每個 partition 分布在不同的機器上，只存一部分資料。
資源不夠則 增加 partition，增加機器
* 資料持久化
順序落盤，提高磁碟讀寫效能； index 和 log 檔案，加快 速度
* 可用性，ha
replication , leader 掛了咋辦？ broker掛了咋辦？ controller掛了咋辦？
* 支援資料零丟失方案
caffe 速覽筆記
blob與tensorflow中的tensor類似，都是用來在節點之間傳遞資料所用，介面也類似，常規的dimension是 資料量n x 通道k x 高度h x 寬度w blob內部存有data和diff兩大塊。前者是傳遞的資料，後者是計算的梯度。由於blob同時存在cpu和gpu，所以有兩種方式來...
筆記 python模組速覽
有些東西，可能不經常用，尤其對於像我這種剛學的小夥伴來說更是如此。對於這部分內容可以不會用，但是一定要了解有這個東西，知道這個東西是什麼，能幹什麼，當我需要的時候可以想到，這個東西可以派上用場，到時再深入學習也為時不晚。目錄 常用內建模組 datetime collections base64 st...
Git命令速覽 git筆記
版本控制系統 vcs 在 git 中的絕大多數操作都只需要訪問本地檔案和資源，不用連網。但如果用 cvcs 的話，差不多所有操作都需要連線網路。因為 git 在本地磁碟上就儲存著所有當前專案的歷史更新，所以處理起來速度飛快。對於任何乙個檔案，在 git 內都只有三種狀態 已提交 committed ...