前面分別聊了
《分布式日誌中心國外篇》
《分布式日誌中心國內篇》
本篇分享下分布式日誌中心的開源產品。
首當其衝的就是elk，當前很多企業都會採用elk來搭建自己的日誌中心,但是真的能幫他們解決什麼問題呢？這個從這麼多商業公司也在做這件事情上或多或少能反映一些問題，我想這其中的原因可能有如下3點：
1、elk使用門檻還是太高，除了安裝部署運維，還是使用，比如日誌接入，日誌解析等。
2、沒有貼近客戶和業務，缺乏完善的管理視角，單純是乙個日誌平台。
3、資料處理欠缺，海量資料管理瓶頸。
其實網路上針對elk的介紹和原理剖析文章專欄，真心不少，在此就不無鉅細的地再嚼舌一次，我從以下幾個點簡單談下我的一些觀點.
1、elk當前具備了比較完善的外掛程式開發機制，不管是elasticsearch，或者是logstash的input/filter/output，還是ui層面的kibana,都支援使用者去開發自定義外掛程式，其實這就形成了一套比較完善的生態，可以讓第三方開發者直接參與進來，根據自己的業務和技術場景來做開發。
2、elk完全開源，截止到2023年，把僅有的付費模組xpack也開源了，只是該付費模組的license許可不同而已，也是謹防當前的一些雲廠商玩家坐收漁利有關。
3、elk產品覆蓋度廣，特別是開源了xpack以後，對於ml/graph/security/apm/sql等高階模組來滿足一些aiops的使用場景。
作為技術同學，可以好好研究下elk原始碼以及設計思想，目前核心**量也是至少達到百萬之巨，自己也在持續學習中，特別在elk7.x發布以後，在一些穩定性，zen2集群演算法，效能上都有不錯改進，在後面的文章會揀一些不錯的技術點來和大家分享下。
其實除了elk以外，還有一家國外的開源產品也是非常值得學習和推薦的，graylog2，目前在儲存檢索這一層直接使用了elasticsearch，但在資料接收，資料管道處理基本都是自己開發的，沒有直接使用logstash，同時也有一套自己的控制台，而沒有採用kibana，整體的**質量很高，在資料接收，處理層支援使用者開發自定義外掛程式，同時在一些資料處理的抽象上也做的不錯，比如stream抽象,contentpack支援使用者上傳，gelf，dsl資料處理等，對於日誌採集，提供了乙個sidebar，配合控制台幫助你快速接入日誌，也支援filebeat/nglog等不同採集工具的管控，總體來說，graylog2為中小企業提供了乙個小而美的日誌中心工具，個人覺得比較缺陷的是控制台，資料接受，處理都在乙個工程中，沒有單獨分離，且不適合複雜且資料規模海量的大集群日誌中心建設，但在一些**質量和一些抽象設計思路很值得學習。
最後說乙個elk技術棧之外的開源產品，那就是grafana下的loki。
乙個水平可擴充套件，高可用性，多租戶的日誌聚合系統，受到prometheus的啟發。它的設計非常經濟高效且易於操作，因為它不會為日誌內容編制索引，而是為每個日誌流編制一組標籤，這又是乙個小而美的全棧日誌產品，整體來看，目前功能還比較單一。
好了，大致介紹了目前3個開源的全棧日誌產品，裡面一些具體的設計和技術細節，會在後面的文章逐步分享出來。
分布式服務如何設計分布式事務
1 如果a b c強相關 考慮採用tcc框架 try confirm cancel bytetcc，himly 阿里的fescar，seata 推薦使用seata tcc框架 2 如果a 與bc並不強相關 考慮可靠訊息最終一致性解決方案，例如a成功後通過傳送kafka事件，bc監聽事件來處理。roc...
Redis設計分布式鎖
通過redis高版本的原子命令 jedis.set lockname,nx px expiretime 分析 redis的set命令可以攜帶複雜引數，第乙個是鎖的key，第二個是value，可以存放獲取鎖的客戶端id，通過這個校驗是否當前客戶端獲取到了鎖，第三個引數取值nx xx,第四個引數 ex ...
如何設計分布式系統
設計分布式系統主要考慮以下四個大點，兩個小點 四個大點 兩個小點 我們都知道，系統出現故障是非常常見的，所以我們應該把處理故障的 當成正常的功能做在架構裡寫在 裡，使得故障真正發生時，系統還可以執行 分布式鎖設計原則 什麼是系統的可伸縮性？如果你的系統對乙個使用者來說是快的，但是在使用者不斷增長的高...