需求背景
項目中有一個頁面，需要在編輯后原地刷新頁面。也就是編輯信息，點保存之后，前端會自動刷新頁面。
技術(shù)方案
- 選擇es作為查詢數(shù)據(jù)源。
如果使用mysql作為查詢數(shù)據(jù)源，需要join 3個表，而且where條件非常復(fù)雜，而且條件包含姓名左右模糊搜索（like '%xxx%'），性能肯定很差。
因此選擇es作為查詢數(shù)據(jù)源
- 點擊保存之后，保存接口先把數(shù)據(jù)存到mysql，再推到es。
推es的方案，選擇用RestHighLevelClient手動雙寫，而不是binlog。
因為一個es索引對應(yīng)mysql多張表，如果用binlog，很難保證數(shù)據(jù)完整性。
另外，我們的寫操作入口比較少，手動雙寫工作量不是很大。
- 保存操作完成之后，發(fā)布一個事件，監(jiān)聽器監(jiān)聽到事件后，異步把數(shù)據(jù)推送es。
1). 用spring的事務(wù)管理器，控制發(fā)布事件的時機在保存操作事務(wù)結(jié)束后，否則監(jiān)聽器可能查不到最新數(shù)據(jù)。
2). 發(fā)布事件的技術(shù)選型
- 如果發(fā)布器跟監(jiān)聽器在同一個微服務(wù)，可以用內(nèi)存事件（java提供了觀察者模式的api，參考java.util.EventListener）
- 如果發(fā)布器跟監(jiān)聽器在不同微服務(wù)，可以用mq
3). 用本地消息表保證事件at least once語義。
- 在保存操作的事務(wù)里，向本地消息表插入一行事件，狀態(tài)初始化為init
- 監(jiān)聽器的邏輯，如果執(zhí)行成功，把本地消息表的時間狀態(tài)改成executed_success
- 監(jiān)聽器的邏輯，如果執(zhí)行失敗，把本地消息表的時間狀態(tài)改成executed_fail
- 如果保存操作的事務(wù)成功了，那么事件在本地消息表肯定存在記錄，增加一個job定時掃描本地消息表中狀態(tài)為非init的記錄，并重試。
4). 如果使用mq發(fā)布事件，如何保證消息一定發(fā)送成功？
- 如果mq支持事務(wù)消息（比如rocketmq），可以使用事務(wù)消息
- 如果mq不支持事務(wù)消息，可以用本地消息表
- 監(jiān)聽器的邏輯，大約需要1.5s，也就是說，保存操作的請求200后，還有約1.5s的數(shù)據(jù)延遲，如果這1.5s內(nèi)，前端自動刷新頁面，拿到的數(shù)據(jù)是不準(zhǔn)的。
1). 使用RestHighLevelClient把數(shù)據(jù)推到es本質(zhì)上是一個http請求，請求200，不代表es可以馬上查詢到數(shù)據(jù)。
2). 數(shù)據(jù)推到es后，數(shù)據(jù)只是存放在內(nèi)存，等待一段時間，才會寫入segment，然后才可以搜索到。
3). 這個時間間隔由es服務(wù)端的refresh_interval參數(shù)控制，這個參數(shù)默認(rèn)是1s，SRE要求最低也是1s，否則可能把集群打掛。另外，客戶端也可以設(shè)置寫入索引后的刷新策略，RefreshPolicy.IMMEDIATE表示立即刷新。
4). 寫入segment，相當(dāng)于建立倒排索引，一個倒排索引分成多個segment。
5). 監(jiān)聽器的邏輯，有3部分耗時，這3部分耗時合計，絕大部分情況下在1.5s內(nèi)
- 發(fā)送http請求，把數(shù)據(jù)推送es
- 1s的時間間隔，數(shù)據(jù)才寫入segment
- 寫入segment本身有耗時
es數(shù)據(jù)延遲解決方案
| 方案 | 技術(shù)實現(xiàn) | 優(yōu)點 | 缺點 |
|---|---|---|---|
| 方案一 | 用戶操作完成后，馬上刷新頁面，查es | 前后端實現(xiàn)簡單，后續(xù)運維成本低 | 數(shù)據(jù)有延遲，產(chǎn)品不接受 |
| 方案二 | 用戶操作完成后，前端sleep 1.5s后再刷新頁面，查es | 后端實現(xiàn)簡單 | 涉及的接口較多（當(dāng)前頁面有5個寫接口，1個讀接口），前端實現(xiàn)復(fù)雜 |
| 方案三 | 從es撈id，其他信息從mysql查 | 查詢es的篩選條件，本身就是有延遲的字段，因此從es撈出的id是不對的 | |
| 方案四 | 保存接口執(zhí)行完業(yè)務(wù)邏輯后，往redis set一個key，表示當(dāng)前登錄用戶執(zhí)行了保存操作，ttl設(shè)置為1.5s；查詢接口執(zhí)行業(yè)務(wù)邏輯前，判斷key是否存在，若存在，從mysql查詢，否則從es查詢 | 可以解決數(shù)據(jù)延遲 | 需要維護mysql與es兩套查詢邏輯，日后需求有變更，兩套方案都要改 |
| 方案無 | 保存接口執(zhí)行完業(yè)務(wù)邏輯后，往redis set一個key，表示當(dāng)前登錄用戶執(zhí)行了保存操作，ttl設(shè)置為1.5s；查詢接口執(zhí)行業(yè)務(wù)邏輯前，判斷key是否存在，若存在，sleep 1.5s | 可以解決數(shù)據(jù)延遲 | 保存接口與查詢接口沒有解耦，查詢接口需要關(guān)注保存接口的邏輯 |
| 方案六 | 查詢接口加一個isReadAfterWrite字段，標(biāo)識本次請求是否是用戶操作完成后的查詢。如果isReadAfterWrite=true，后端sleep 1.5s，再查es；如果isReadAfterWrite=false，正常執(zhí)行邏輯 | 可以解決數(shù)據(jù)延遲 |
綜合考慮后，選擇方案六
思考
- 為了保障數(shù)據(jù)一致性，就要犧牲部分耗時
- 接口的耗時不用追求絕對的最優(yōu)，要在保障業(yè)務(wù)邏輯的可用性前提下，盡量耗時短
- 如果跟業(yè)務(wù)邏輯可用性沖突時，top1需要保障的是業(yè)務(wù)邏輯的可用性
- 如果一個頁面需要查es，篩選條件應(yīng)該是不可變的字段，比如姓名、國籍這種，這樣才可以用es撈id，其他信息從mysql查
