文章目錄

• • • 系統設計一般方法論
    • 1. 監控系統設計
    • • 1. scenario 監控哪些東西
      • 2. service 服務
      • 3. store 具體的數據模型
      • 4. scale
    • 2 搜索系統設計
    • • 1. scenario
      • 2. service
      • 3. store
      • 4. scale

系統設計一般方法論

4s

scenario
業務模塊
容量：對應的數據量，對應的qps（在服務規劃和存儲規劃的時候會用到）

service
對應的服務模塊有哪些，服務架構設計

store
根據不同個業務類型選型不同的存儲
存儲層的設計，需要哪些字段，哪些表，進行存儲

scale
系統的伸縮性能設計

1. 監控系統設計

1. scenario 監控哪些東西

對應的監控可能產生的數據量級

查詢監控：

查詢耗時

查詢無結果

請求異常
數據流監控：

數據流量監控(每分鐘的寫入量級)

數據延遲監控

數據同步異常監控

服務器的監控一般是有另外的更基礎通用的監控系統

2. service 服務

整個業務的架構設計，數據生產，采集，存儲，使用數據監控
生產端可以采用sdk等，采集使用filebeat+kafka+logstash
存儲使用elasticsearch
監控報警使用grafana+dingding

3. store 具體的數據模型

查詢監控：

耗時： 記錄查詢的耗時，query, sessionid來做全鏈路的監控 use_time,query,session_id

無結果： 記錄結果數，請求參數 query, result_count

異常：當次請求是否處于異常狀態 query, error_msg, error_stack
數據流監控：

流量 table,id,index

延遲監控 table,id,delay_time

異常監控 tabel,id,message,error_msg,error_stack

4. scale

根據監控數據的容量，每天1t,保存多少天14天，規劃es的集群大小
根據監控數據的生產速度，決定kafka的容量，lagstash的數量，es的配置
寫入大于5w，盡量使用本地ssd，大磁盤，冷熱隔離的模式

2 搜索系統設計

1. scenario

搜索有哪些場景，搜用戶，搜帖子
對應的數據量，qps
數據量 用戶2億， 帖子4kw
qps 2k+
性能指標要求 999的返回時間200

2. service

indexer:
負責從數據源同步數據到es
增量和全量的數據處理

search-server: 單個服務200qps,最少兩個服務
負責從es中進行檢索操作

rerank-server

3. store

elasticsearch 配置，節點數量， mapping設計， 單節點按照1000qps設計

4. scale

監控，數據積壓，擴容

總結

以上是生活随笔為你收集整理的系统设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。