快取技術方案改造思考

這是我對一個正在進行的重構專案，快取技術方案改造點之一的一個想法：
rc現有的實時快取（其實也是準實時，失效時間的存在）設計：

存在的問題：現有的實時快取方案（也並非真正意義上的實時，快取失效時間的存在），與上游核心系統耦合度較高，核心系統強依賴下游欠核心系統，而且目前的查詢服務效能也存在問題，比如區域銷售豆腐塊介面返回的資料量大，並且從tair->rc，rc->delivery需要經過兩次網路傳輸，這之間網路傳輸及序列化、反序列化消耗大，而且出現問題時，由於排查鏈路和時間週期都長；

升級方案的的思考：解耦上游核心系統（如delivery）與資源中心的HSF服務，rc維護資料庫資料與tair(ldb)叢集資料的一致性(準實時)，外部系統的查詢直連tair(ldb)，不走rc的HSF服務，實現rc系統的讀寫分離，初步設計如下：

這裡之所以選擇ldb是因為它tair持久化的儲存引擎，使用ssd盤儲存資料，保證了資料的安全不丟失，並且讀寫效能遠遠高於db；
藉助TTD中介軟體指定一臺機器執行定時任務，定時任務將db中上一次定時任務結束到這一定時任務開始前變化的資料，從資料庫中篩選出來，根據這些資料匹配列表ldb對應中key,針對每一個value值變化的key都去db中撈出key對應的新value值，然後invalid 目前ldb中的value，然後將新value put到ldb中，這樣就維護了，資料庫與ldb資料的一致性；
rc的讀client（如delivery）需要前置mdb快取從ldb中拿到的資料（訪問量巨大的話，如不做mdb快取，ldb壓力很大），查詢的時候首先去查詢mdb，若有資料，則直接返回，若沒有再去查詢ldb，在這個設計中，讀client不需要呼叫任何rc的查詢服務，rc應用只是負責db與ldb資料的一致性，實現了讀client與rc的解耦，上游的如delivery這樣核心系統不再需要依賴下游的欠核心的rc系統，交易鏈路精簡；
這個設計存在的問題：還沒法做到完全的實時（定時間隔的存在），選擇一個較為合理的定時間隔，平衡系統解耦的好處與實時查詢的犧牲，實現準實時的系統解耦，還是值得的；
各位看到此文章的大牛，請幫忙評估一下此改造方案的可行性及改造方案的優缺點，期待各位給出寶貴的建議，謝謝大家！