Redis
淘汰策略[六種]
https://blog.csdn.net/ligupeng7929/article/details/79603060
https://blog.csdn.net/jcsyl_mshot/article/details/80645362
LRU是Redis唯一支持的回收算法
no-eviction:不刪除策略
# 對於所有的key
allkeys-lru：刪除最近訪問頻率低的key
allkeys-random：隨機刪除一部分key
# 對於設置expire
volatile-lru：刪除最近訪問頻率低的key
volatile-random：隨機刪除一部分key
volatile-ttl：優先刪除剩餘時間(time to live,TTL) 短的key
# 清理策略
無外乎就是 清理非熱點數據 訪問頻率 最近訪問時間 剩餘的有效期時間
緩存的問題
https://blog.csdn.net/wang0112233/article/details/79558612
# 緩存穿透
由於緩存不命中，每次都要查詢持久層。從而失去緩存的意義
解決方法：
0、可以校驗key的格式，不滿足，直接返回錯誤信息
1、緩存層緩存空值
–緩存太多空值，佔用更多空間。（優化：給個空值過期時間）
–存儲層更新代碼了，緩存層還是空值。（優化：後臺設置時主動刪除空值，並緩存把值進去）
2、將數據庫中所有的查詢條件，放到布隆過濾器中。當一個查詢請求來臨的時候，先經過布隆過濾器進行檢查，如果請求存在這個條件中，那麼繼續執行，如果不在，直接丟棄
# 緩存雪崩
1.在緩存失效後，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待
2.可以通過緩存reload機制，預先去更新緩存，再即將發生大併發訪問前手動觸發加載緩存
3.不同的key，設置不同的過期時間，讓緩存失效的時間點儘量均勻
4.做二級緩存，或者雙緩存策略。A1爲原始緩存，A2爲拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設置爲短期，A2設置爲長期
# 熱點key（訪問熱點key的頻率很高）
怎麼提高緩存命中
沒有從緩存中獲取到，就從數據庫裏面獲取，然後再存入到內存中
一致性哈希算法[集羣]
https://blog.csdn.net/u013851082/article/details/68063446
MySQL
https://blog.csdn.net/tubro2017/article/details/88797336
其他問題
# mysql的索引存儲的是什麼？
關聯主鍵，innodb聚簇索引，索引時關聯到主鍵，也就關聯到數據
# 爲什麼用主鍵查詢比索引查詢快
所以用主鍵查詢 效率要快於索引，少了一道流程。innodb不手動設置主鍵的話，默認也會內部創建主鍵的，就是因爲這層關係
# mysql查詢複雜度，和插入數據的複雜度
logn
# 聚簇索引和非聚簇索引
聚簇索引：將數據存儲和索引放到了一塊，找到索引也就找到了數據；
非聚簇索引：將數據存儲與索引分開結構，索引結構的葉子節點指向了數據的對應行
MySQL數據庫優化的八種方式
1、選取最適用的字段屬性
2、使用連接（JOIN）來代替子查詢(Sub-Queries)
3、事務
4、使用索引
5、優化sql語句
Tidb
tidb架構
TIDB server （接收sql，並且處理sql）（集羣，3個TIDB serve）
PD server（管理，集羣，3個PD server）
TIKV server（存儲數據，集羣，3個TIKV server）
TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並通過 PD 找到存儲計算所需數據的 TiKV 地址
# 水平擴展
無限水平擴展是 TiDB 的一大特點，這裏說的水平擴展包括兩方面：計算能力（TIDB server）和存儲能力（TIKV server）；
# 高可用
高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個組件都能容忍部分實例失效，不影響整個集羣的可用性
中間件
FastDFS文件存儲系統[小型]
- 一般都交給七牛雲來存儲圖片和視頻
RMQ[RabbitMQ]
# AMQP協議
高級消息隊列協議
發佈訂閱模式
通過交換機與隊列綁定的key，發佈到隊列裏
交換機常用的有三種：
direct，點對點，需要全部匹配到key了，才把消息發到該隊列裏
fanout，發佈的消息，綁定的隊列都收到消息
topic，匹配，發佈的消息，與該key匹配上的隊列收到消息，'#'代替一個單詞或多個詞，* 代表一個詞
解決消息丟失
# ack（消息確認）
# 持久化
# 發送消息前，將消息持久化到數據庫，並記錄消息狀態（可靠消息服務）
# 生產者確認（publisher confirm）
# 解決消息丟失問題
消息確認機制
當消息處理完成後，給server端發送一個確認消息（ACK），來告訴server端可以刪除該消息了，如果連接斷開時候，server端沒有收到消費者發出的確認消息（ACK），則會把消息轉發給其他保持在線的消費者
通過消息確認機制（ACK）來實現，當消費者獲取消息後，會想mq發送回執ACK，告知消息以及被接收了，可以從隊列裏刪除了
zookeeper
協調中心，調度中心
kafka
生產消費模式，訂閱一個topic，發佈的消息到該topic，訂閱該topic的就收到了該消息
高吞吐，kafka集羣
ES[elasticsearch]
儲存數據用的，存儲的數據類型爲json
put /index/type/1 存儲數據，可以寫json的格式去查詢
get /index/type/1 獲取數據
delete /index/type/1 刪除數據
head /index/type/1 判斷數據是否存在，返回狀態碼，200或404
# 分詞
celery
異步和定時框架