数据亲和架构--数据同步

        数据亲和架构核心要解决数据和程序的绑定问题，那么数据在进程间同步就尤为重要。因为性能的关系，增量同步是首选，全量同步只有在初始化或者出现异常的情况下，才会考虑。在流数据中，因为有时序，比较容易实现，而在静态数据中，比如文件或者数据库中，通常没有严格的时序，只有快照，要做增量比较困难。

        以物理时间流动为参照系，任何一个数据集都可以分为某个时间点的快照，以及后续的变更。而该时间点快照即视为静态数据，除非在应用层里为这些数据插入时序信息，否则是难以做增量同步的。作为一个通用解决方案，不能假设应用层会加入时序信息。在该时间点之后的变更，只要流经同步系统，系统就可以自动为这些变更增加时序，实现增量同步。于是乎，数据同步就可以被分解成两个部分，一是静态数据同步，另一个是天然的增量同步。

        将静态数据视为一个文件，那么文件的增量同步系统，如rsync和git等系统已经为我们提供现成的解决方案，完成可以借鉴。需要注意的是，和传统的二进制或者文本文件同步不一样，浮点数据具有特殊性，同样一个浮点数，可以有多种表现方式，这些值在现实中是一样的，但在二进制层面却完全不同，可能会导致无效的增量变化。幸运的是，数据库在浮点数格式化这块为我们提供了不错的方法。

        虽然数据库标准查询接口只提供快照，但主流的数据库，都额外提供了CDC系统，帮助我们捕获数据库本身数据的增量变化，事实上，数据库的binlog本身就是一个严格时序的数据流存储方式。因此数据库同步依然符合上述模式：快照+增量。而文件类型的数据存储系统，和数据库不同，可以在写入之前截获数据流来实现增量变更信息。内存类型的数据存储也是同样解决方案。

        数据同步的另外一个问题，就是一致性问题。由于同步导致数据分布在多个节点或者进程中，也因此引入中了分布式系统中，必须面对的CAP原则。具体要达到哪种程度的一致性，可以由应用层制定策略，底层架构实现对应的机制即可。