« 上一篇下一篇 »

数据一致性原则

不论是Scale Up还是Scale Out,不管如何设计架构,保证数据最终一致性都是绝对不能违背的原则,保证这个原则的重要性大家肯定非常清楚。

    数据一致性的保证就像事务完整性一样,在我们对系统进行Scale Out设计的时候,也可能会遇到一些问题。当然,如果是Scale Up,可能就很少遇到这类麻烦了。当然,在很多人眼中,数据的一致性在某种程度上也是属于事务完整性的范畴。不过这里为了突出其重要性和相关特性,将它单独提出来分析。

    如何在Scale Out的同时较好地保证数据一致性呢?这个问题和保证事务完整性一样让我们头痛,它同样受到了很多架构师的关注。经过很多人的实践,大家最后总结出了BASE模型。即:基本可用,柔性状态,基本一致和最终一致。这几个词看似复杂深奥,其实大家可用简单地理解为非实时的一致性原则。

    也就是说,应用系统通过相关的技术实现,让整个系统在满足用户使用的基础上,允许数据短时间内处于非实时状态,而通过后续技术来保证数据在最终保证处于一致状态。这个理论模型说起来挺简单,但实际实现过程中会遇到不少难题。

    首先,第一个问题是需要让所有的数据都是非实时一致吗?大多数朋友肯定是投反对票的。如果不是所有的数据都是非实时一致,如何确定哪些数据需要实时一致,哪些数据只需要非实时的最终一致呢?其实,这基本上是一个各模块业务优先级的划分问题,对于优先级高的术语保证数据实时一致性的阵营,而优先级略低的应用,则可以考虑将其划分到允许短时间内不一致而最终一致的阵营。这是一个非常棘手的问题,不能随便拍脑袋就决定,需要通过非常详细地分析和仔细地评估才能做出决定。因为不是所有数据都能出现系统在短时间不一致的状态,也不是所有数据都可以通过后期处理能最终达到一致的状态,所以至少这两类数据需要实时一致。如何区分这两类数据,就必须分析业务场景和了解商业需求后进行充分地评估才能得出结论。

    其次,如何让系统中的不一致数据达到最终一致?一般来说,必须将这类数据所涉及的业务模块和需要实时一致数据的业务模块明确地划分开来。然后通过相关的异步机制技术,利用相应的后台进程,通过系统中的数据、日志等信息将当前并不一致的数据进行进一步处理,使最终数据处于完全一致的状态。对于不同的模块使用不同的后台进程,既可以避免数据出现紊乱,也可以并发执行,提高处理效率。如对用户的消息、通知之类的信息,就没有必要做到严格的实时一致性,只要先记录需要处理的消息,然后让后台的处理进程依次处理,避免造成前台业务的拥塞。

    最后,避免实时一致与最终一致两类数据的前台在线交互。由于两类数据状态的不一致性,很可能导致两类数据在交互过程中出现紊乱,应该尽量让所有非实时一致的数据和实时一致数据在应用程序中有效隔离。甚至在有些特别的场景下,记录在不同的MySQL Server中来进行物理隔离是有必要的。

 

« 上一篇下一篇 »