資料親和架構核心要解決資料和程式的繫結問題，那麼資料在程序間同步就尤為重要。因為效能的關係，增量同步是首選，全量同步只有在初始化或者出現異常的情況下，才會考慮。在流資料中，因為有時序，比較容易實現，而在靜態資料中，比如檔案或者資料庫中，通常沒有嚴格的時序，只有快照，要做增量比較困難。
以物理時間流動為參照系，任何乙個資料集都可以分為某個時間點的快照，以及後續的變更。而該時間點快照即視為靜態資料，除非在應用層裡為這些資料插入時序資訊，否則是難以做增量同步的。作為乙個通用解決方案，不能假設應用層會加入時序資訊。在該時間點之後的變更，只要流經同步系統，系統就可以自動為這些變更增加時序，實現增量同步。於是乎，資料同步就可以被分解成兩個部分，一是靜態資料同步，另乙個是天然的增量同步。
將靜態資料視為乙個檔案，那麼檔案的增量同步系統，如rsync和git等系統已經為我們提供現成的解決方案，完成可以借鑑。需要注意的是，和傳統的二進位制或者文字檔案同步不一樣，浮點資料具有特殊性，同樣乙個浮點數，可以有多種表現方式，這些值在現實中是一樣的，但在二進位制層面卻完全不同，可能會導致無效的增量變化。幸運的是，資料庫在浮點數格式化這塊為我們提供了不錯的方法。
雖然資料庫標準查詢介面只提供快照，但主流的資料庫，都額外提供了cdc系統，幫助我們捕獲資料庫本身資料的增量變化，事實上，資料庫的binlog本身就是乙個嚴格時序的資料流儲存方式。因此資料庫同步依然符合上述模式：快照+增量。而檔案型別的資料儲存系統，和資料庫不同，可以在寫入之前截獲資料流來實現增量變更資訊。記憶體型別的資料儲存也是同樣解決方案。
資料同步的另外乙個問題，就是一致性問題。由於同步導致資料分布在多個節點或者程序中，也因此引入中了分布式系統中，必須面對的cap原則。具體要達到哪種程度的一致性，可以由應用層制定策略，底層架構實現對應的機制即可。
資料親和架構 緣起
資料親和架構並沒有否定其他架構，尤其是微服務架構的合理性，而是從另外乙個視角來重新審視整個架構，做出補充。讓資料和業務邏輯具備更強的親和性，故命名為資料親和。微服務架構提出了乙個理念，每個服務劃分成更細粒度的服務單元。每個單元的職能更加單一，降低了服務單元的複雜度和耦合性，但它同時增加系統整體複雜度...
資料親和架構 流式計算
關於計算有很多名詞，比如實時計算 分布式計算，以及這裡提到流式計算等等。他們是從計算形勢的不同維度來描述，不必爭議孰優孰劣。流式計算主要從資料的形態來定義的一種計算方式，顧名思義，這種資料如流水一般，沒有終點。乙個有爭議的特徵的是，流式資料之間是否具有時序性，我贊同流式資料之間應該假定為具有時序性，...
多組資料之親和數
題目描述 如果a的因子和等於b，b的因子和等於a，且 a b，則稱a，b為親密數對。比如 220的所有真約數 即不是自身的約數 之和為 1 2 4 5 10 11 20 22 44 55 110 284 284 的所有真約數和為 1 2 4 71 142 220 你的任務就編寫乙個程式，判斷給定的兩...