這幾天試著著手前後端同步的架構，但依然存在一些理論上問題。之前的文章似乎全都以線性資料為前提做討論的，對於離散資料的同步確實比線性資料困難。因為客戶端無法通過離散資料計算出查詢可能產生的id序列，這時就需要與伺服器保持通訊。
乙個包含複雜查詢條件的查詢，它可能查詢的id序列就是前端無法計算的。比如查詢某個使用者在某一時間段的發言，由於這些發言之間的id並沒必然聯絡，這個請求就需要遍歷所有資料才能找到所屬的部分（除非前後端有為此同步索引，但這個成本非常高，不考慮它）。然而客戶端的資料儲存是不完全的，所以這個工作需要由伺服器端來完成。
資料如果存在刪除操作，實際上也是離散資料。最初我的想法能不能將被刪除的條目標記為已刪除，而不去影響結構呢？但是即便如此，在需要查詢特定數量的記錄時就會使id序列無法計算。比如有乙個聊天室，乙個使用者在這個聊天室已經有50條聊天記錄後才加入，現在已經聊到了100條。這時管理員發現，id（從1開始計數）為16的記錄是廣告，並把它標記為了刪除狀態。如果此時這個使用者需要查詢第8頁的資料（每頁10條計），那麼按照線性id的計算會得到id從71到80的記錄。但由於id為16的記錄是刪除的，它不該算入統計，所以真正的第8頁id應該是從72到81。也就是說，對資料的刪除會破壞線性資料結構，使其變為離散資料。所以對於需要刪除的資料，我們可能也需要請求伺服器來獲取查詢對應的真正id序列（其它做法不是沒有，但還需要從適用性分析來進一步研究）。
這篇暫時就討論這些，關於資料同步的問題還有很多需要研究的地方。
ElasticSearch的資料同步問題怎麼處理？
概述 最簡單的一種，在將資料寫到mysql時，同時將資料寫到es，實現資料的雙寫。優點 業務邏輯簡單。缺點 硬編碼 es的編碼 業務耦合性高 效能較差 mysql es會降低系統效能 存在雙寫失敗丟資料風險 如果資料有強一致性的要求，那就必須加上事務，效能又會降低 es系統不可用 應用系統和es之間...
資料同步遇到的問題
背景 兩個系統a和b，b需要同步a的部分資料，現在b使用定時任務呼叫a提供的介面實現同步。問題 發現b查詢歷史資料的需求無法實現 原因 同步時若a刪除了某條屬性，同步到b後該屬性不會顯示，也不能查到該屬性任何資訊 a,b的受眾不同，a只需要展示有用的資料，b需要展示所有歷史資料，對資料庫的操作只集中...
離散化問題
題目傳送 uvalive 4127 the sky is the limit 大白書離散化簡單題。找了半天錯誤，居然是少輸出乙個空行。頓時感覺自己萌萌噠。其中計算幾何是套的之前留下的模板。ac include include include include include include inclu...