需求背景
項目中有一個頁面，需要在編輯后原地刷新頁面拟枚。也就是編輯信息薪铜，點保存之后众弓，前端會自動刷新頁面。
技術方案
- 選擇es作為查詢數(shù)據(jù)源隔箍。
如果使用mysql作為查詢數(shù)據(jù)源谓娃，需要join 3個表，而且where條件非常復雜蜒滩，而且條件包含姓名左右模糊搜索（like '%xxx%'）滨达，性能肯定很差。
因此選擇es作為查詢數(shù)據(jù)源
- 點擊保存之后俯艰，保存接口先把數(shù)據(jù)存到mysql捡遍，再推到es。
推es的方案竹握，選擇用RestHighLevelClient手動雙寫画株，而不是binlog。
因為一個es索引對應mysql多張表啦辐，如果用binlog谓传，很難保證數(shù)據(jù)完整性。
另外芹关，我們的寫操作入口比較少续挟，手動雙寫工作量不是很大。
- 保存操作完成之后充边，發(fā)布一個事件庸推，監(jiān)聽器監(jiān)聽到事件后，異步把數(shù)據(jù)推送es浇冰。
1). 用spring的事務管理器贬媒，控制發(fā)布事件的時機在保存操作事務結束后，否則監(jiān)聽器可能查不到最新數(shù)據(jù)肘习。
2). 發(fā)布事件的技術選型
- 如果發(fā)布器跟監(jiān)聽器在同一個微服務际乘，可以用內(nèi)存事件（java提供了觀察者模式的api，參考java.util.EventListener）
- 如果發(fā)布器跟監(jiān)聽器在不同微服務漂佩，可以用mq
3). 用本地消息表保證事件at least once語義脖含。
- 在保存操作的事務里，向本地消息表插入一行事件投蝉，狀態(tài)初始化為init
- 監(jiān)聽器的邏輯养葵，如果執(zhí)行成功，把本地消息表的時間狀態(tài)改成executed_success
- 監(jiān)聽器的邏輯瘩缆，如果執(zhí)行失敗关拒，把本地消息表的時間狀態(tài)改成executed_fail
- 如果保存操作的事務成功了，那么事件在本地消息表肯定存在記錄，增加一個job定時掃描本地消息表中狀態(tài)為非init的記錄着绊，并重試谐算。
4). 如果使用mq發(fā)布事件，如何保證消息一定發(fā)送成功归露？
- 如果mq支持事務消息（比如rocketmq）洲脂，可以使用事務消息
- 如果mq不支持事務消息，可以用本地消息表
- 監(jiān)聽器的邏輯剧包，大約需要1.5s恐锦，也就是說，保存操作的請求200后玄捕，還有約1.5s的數(shù)據(jù)延遲踩蔚，如果這1.5s內(nèi)，前端自動刷新頁面枚粘，拿到的數(shù)據(jù)是不準的馅闽。
1). 使用RestHighLevelClient把數(shù)據(jù)推到es本質(zhì)上是一個http請求，請求200馍迄，不代表es可以馬上查詢到數(shù)據(jù)福也。
2). 數(shù)據(jù)推到es后，數(shù)據(jù)只是存放在內(nèi)存攀圈，等待一段時間暴凑，才會寫入segment，然后才可以搜索到赘来。
3). 這個時間間隔由es服務端的refresh_interval參數(shù)控制现喳，這個參數(shù)默認是1s，SRE要求最低也是1s犬辰，否則可能把集群打掛嗦篱。另外，客戶端也可以設置寫入索引后的刷新策略幌缝，RefreshPolicy.IMMEDIATE表示立即刷新灸促。
4). 寫入segment，相當于建立倒排索引涵卵，一個倒排索引分成多個segment浴栽。
5). 監(jiān)聽器的邏輯，有3部分耗時轿偎，這3部分耗時合計典鸡，絕大部分情況下在1.5s內(nèi)
- 發(fā)送http請求，把數(shù)據(jù)推送es
- 1s的時間間隔坏晦，數(shù)據(jù)才寫入segment
- 寫入segment本身有耗時
es數(shù)據(jù)延遲解決方案
| 方案 | 技術實現(xiàn) | 優(yōu)點 | 缺點 |
|---|---|---|---|
| 方案一 | 用戶操作完成后椿每，馬上刷新頁面伊者，查es | 前后端實現(xiàn)簡單英遭，后續(xù)運維成本低 | 數(shù)據(jù)有延遲间护，產(chǎn)品不接受 |
| 方案二 | 用戶操作完成后，前端sleep 1.5s后再刷新頁面挖诸，查es | 后端實現(xiàn)簡單 | 涉及的接口較多（當前頁面有5個寫接口汁尺，1個讀接口），前端實現(xiàn)復雜 |
| 方案三 | 從es撈id多律，其他信息從mysql查 | 查詢es的篩選條件痴突，本身就是有延遲的字段，因此從es撈出的id是不對的 | |
| 方案四 | 保存接口執(zhí)行完業(yè)務邏輯后狼荞，往redis set一個key辽装，表示當前登錄用戶執(zhí)行了保存操作，ttl設置為1.5s相味；查詢接口執(zhí)行業(yè)務邏輯前拾积，判斷key是否存在，若存在丰涉，從mysql查詢拓巧，否則從es查詢 | 可以解決數(shù)據(jù)延遲 | 需要維護mysql與es兩套查詢邏輯，日后需求有變更一死，兩套方案都要改 |
| 方案無 | 保存接口執(zhí)行完業(yè)務邏輯后肛度，往redis set一個key，表示當前登錄用戶執(zhí)行了保存操作投慈，ttl設置為1.5s承耿；查詢接口執(zhí)行業(yè)務邏輯前，判斷key是否存在伪煤，若存在加袋，sleep 1.5s | 可以解決數(shù)據(jù)延遲 | 保存接口與查詢接口沒有解耦，查詢接口需要關注保存接口的邏輯 |
| 方案六 | 查詢接口加一個isReadAfterWrite字段带族，標識本次請求是否是用戶操作完成后的查詢锁荔。如果isReadAfterWrite=true，后端sleep 1.5s蝙砌，再查es阳堕；如果isReadAfterWrite=false，正常執(zhí)行邏輯 | 可以解決數(shù)據(jù)延遲 |
綜合考慮后择克，選擇方案六
思考
- 為了保障數(shù)據(jù)一致性恬总，就要犧牲部分耗時
- 接口的耗時不用追求絕對的最優(yōu)，要在保障業(yè)務邏輯的可用性前提下肚邢，盡量耗時短
- 如果跟業(yè)務邏輯可用性沖突時壹堰，top1需要保障的是業(yè)務邏輯的可用性
- 如果一個頁面需要查es拭卿，篩選條件應該是不可變的字段，比如姓名贱纠、國籍這種峻厚，這樣才可以用es撈id，其他信息從mysql查
