数据亲和架构--一致性

        数据亲和架构强调数据和应用的绑定，这意味着，同一份数据是分布在多个服务的内存中，因此系统是分布式架构。关于分布式系统中，如何管理数据一致性的讨论和文章已经够多了，在此没有必要花太多文字复述一遍。这里更多的是从实践的角度来分析数据一致性问题。

        在一个进程中，多个线程对同一个数据修改，顺序不同，会导致最终结果的不同。锁的机制实际上就确保线程按照顺序对数据进行修改，使得结果符合预期，但不能确保最终结果是一致的。如果将这些修改操作序列化，除非数据与时间、顺序有关，则结果将最终一致。

        分布式系统的一致性在技术上远比多线程复杂，跨进程跨网络操作远程数据，失败是常态，因此要确保修改成功，需要引入多次确认。根据CAP原则，最终一致性是分布式系统的普遍选择，因为从业务角度来看，只要在需要的时候，数据是一致就可以了，必须强一致性的应用场景实际上并没有那么普遍。

操作序列化，对确保最终一致性，甚至强一致性，是基本手段，而消息队列则是这种系统设计的最佳实践。但我们也要注意到，并不是所有的操作都需要序列化，比如心跳，只要最后一个心跳到达，之前的所有心跳都可以忽略。

        强一致性在特定业务场景是需要的，比如常常提到的转账，就像数据库提供事务，在分布式系统中，通常以分布式事务来解决。从DTS衍生出多种解决方案不再赘述。而在我看来，这种模式实在难以处理，系统也难以维护。我不反对这些理论，也赞成这些技术的发展，只是认为在工程实践中，可以采用更简单的方式来完成，规避这些通用解决方案带来的技术风险。

        每个账号天生就是分布的，因此将对一个账号的修改和读写，归于同一服务来完成，就能够避免分布式的难题。剩下的问题就是一个事务会被划分到多个步骤，每个步骤由不同服务来完成，这是分布式事务要解决的问题。我们知道，影响一致性的原因在于数据的修改，以及之后的读取。将这些操作集中在一个服务中，则这些分布式事务的难以将不复存在。

        简单的说，对单个对象的操作事务集中在一个服务中，实现CA；而将不同对象分散在多个服务，实现分布P。对于整个系统来看，这个方案存在通用性缺陷，但并不违反CAP原则，还带来了强一致性和性能，具有很高的实践价值。