一致性简述
数据一致性是保证多个系统中相同的数据保持一致，用户可以看到最新更新的数据，尤其对于双写的数据，要求两份数据要保证完全一样。
数据一致性分类
数据一致性分为强一致性、弱一致性和最终一致性。
- 强一致性，每一次的更新操作完成后，系统将会看到最新的更新数据，数据之间是实时更新同步。
- 弱一致性，与强一致性相对应，每次更新操作后，系统不能保证看到最新的更新数据。系统不保证所以的数据可靠写入。
- 最终一致性，是强一致性和弱一致性的折中情况，或者说是弱一致性的特定形式。系统不保证所有数据写入可以被立刻看到，但保证数据最终会呈现上一次更新操作的值。
强一致性因为要求严格而且不易保证，弱一致性实现起来意义不大，所以在生产环境中都少有使用，绝大多系统依赖于最终一致性，在保证数据更新可以被看到和相同数据一致的前提下，尽可能减少延迟。
最终一致性
保证最终一致性的方法大致分为四种，配置更新记录表、异步消息、补偿操作和独立系统负责异常事务的恢复。
配置更新记录表
利用数据库表记录每次数据的操作情况。记录表应该包括数据操作的类型，数据具体信息和时间戳等，当系统故障重启之后，使用记录表中记录恢复系统因为中断引起的数据不一致问题。另外记录表对于排查数据问题也是极其重要的事实依据。异步消息
异步发送消息给第三方系统或者两个系统之间的通信，常用到的消息系统如activemq，kafka和rocketmq等，这些中间件系统可以独立于数据操作的系统之外保持数据信息。系统出现故障时，消息驻留在中间件中不会丢失，而系统恢复之后可以重新消费消息。异步发送的目的也在于把发送消息的逻辑和数据更新操作独立开来，两者互不影响，尽可能降低因为发送消息带来的数据操作的延迟。异步消息方式将数据同步的操作按照功能隔离开，可以保证各个功能模块相互之间不受影响，但同时业务数据同步可能产生延迟埋下了隐患。补偿操作
补偿操作最常见的例子就是回滚操作，数据系统发生故障后，要把之前已经执行的但尚未执行完的操作回退到之前状态后再一次执行操作。常见的就是银行取款场景，如果取款失败，需要把已经完成的扣款加回到原账号中，重新执行取款。
也有系统会根据自身业务具体逻辑把之前尚未完成操作的数据做特定的操作，例如直接设置为无效等。这些操作都是补偿操作。独立系统负责异常事务的恢复（简称独立系统）
这是在数据一致性保证中最有效的手段，第三方独立的系统负责所有异常事务，有效保证数据正确性不受操作数据系统的限制。独立系统适合大业务，大数据系统，只有对于数据量操作极大的情况下，引入另外的独立系统所产生的开发和运维成本才值得。相对而言小型系统不适用独立系统，因为其成本过高，很有可能超过了数据系统本身所产生的价值。
实际系统应用
这里列举一个我实际开发的例子来讨论数据一致性系统的设计与实现。业务设计要求数据双写，先写入mysql数据库，然后同步至HBase中，方便各个用户端根据自身需求访问不同类型的数据库。
实现方式
首先系统属于轻量级系统，排除独立系统负责异常事务的恢复这种方式，我们在配置更新记录表、异步消息和补偿操作三种方式中选择；
其次业务先写入mysql数据库，再双写到HBase中，整个操作都是单一的原子性操作，不存在执行中途被中断，因此不需要使用补偿操作，如果多个原子性操作顺序执行的情况下，要考虑事务性和补偿操作；
剩下的两种方式异步消息和配置更新记录表。同步数据具有幂等性，换句话说多次更新一条记录为同样数据不会影响到数据的正确性。幂等性是异步消息方式实现最有利的保证，在消费消息时即使某些消息被多次消费也不会影响数据准确。配置更新记录表记录下所有操作，为之后系统恢复提供依据。
具体实现
监听mysql数据库的binlog，每次mysql数据库的insert、update和delete操作发送消息。消息队列获取消息同步HBase。使用中间件保证没有消费的消息不会丢失并且如果消费失败可以重复消费；
如果消息消费失败，将重新放回队列，这时会产生消息顺序与产生的时间顺序不一致的情况，可能会出现之前未消费完的消息内容覆盖之后的消息，例如在10：30分一条更新数据库的消息因为失败放回到队列中，这样排在10:31的数据之后，10:31消息更新之后再执行10:30的消息，就会产生旧数据覆盖新数据的问题。所以每次消费消息时我们会记录最新消费的时间戳，如果程序重启，我们从更新记录表获取最近一次更新的时间戳。消息到来时判断消息的时间戳如果在记录的最新时间戳之前那么直接遗弃，只有在之后的消息才会被执行。
判断时间戳如果每次访问更新记录表会因IO操作而产生性能损耗，数据量不大时，本地内存存储时间戳是一个不错的实践经验，耗费的内存比起提升的性能显得微不足道。
分布式部署时，每台服务器的程序都保存着当前自身消费消息的最新时间戳。假如同一时刻更新两条mysql数据，而两条消息会更新HBase的同一个行的同一列，如果两条消息被分配到不同的服务器上处理，脏数据可能覆盖正确数据。这种情况，要首先利用MQ特性的中partition概念将相同rowkey发送到同一个consumer中，而同一个consumer的多线程消费时需要利用本地锁确保同一个时刻只有一条线程修改HBase。
最后，对于数据一致性系统设计的一个小建议。在更新同步时可能出现的数据错误，例如批量更新mysql数据库时候，最有可能因为qps升高而导致一些数据不能更新。对于这一类似的情况，在条件允许的情况下对系统拆分，分解为不同的小系统，执行单一功能职责。而之间的通信利用中间件，这其实也是独立系统负责异常事务的恢复方式的简化版，当然拆分需要适度，不要导致服务数量的爆炸，这样反而不易于维护。
