java架构师指南:微服务如何进行数据库管理

    分布式数据管理(CRUD)解决方案之前,有必要介绍下CAP原理和最终一致性相关概念。     CAP原理(CAPTheorem)     在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick...

    分布式数据管理(CRUD)解决方案之前,有必要介绍下CAP原理和最终一致性相关概念。

attachments-2020-09-xZIsfnlv5f60a2c911231.jpg

    CAP原理(CAPTheorem)

    在足球比赛里,一个球员在一场比赛中进三个球,称之为帽子戏法(Hat-trick)。在分布式数据系统中,也有一个帽子原理(CAPTheorem),不过此帽子非彼帽子。CAP原理中,有三个要素:

    一致性(Consistency)

    可用性(Availability)

    分区容忍性(Partitiontolerance)

    CAP原则是指这三个要素只能同时达到两个点,不可能同时照顾到这三个要素。

    因此,在设计分布式体系结构时,必须进行权衡。对于分布式数据系统,分区容限是基本要求,否则将失去价值。因此,分布式数据系统的设计要在一致性和可用性之间取得平衡。

    对于大多数WEB应用程序,实际上并不需要强一致性。因此,牺牲一致性以换取高可用性是大多数分布式数据库产品的方向。

    当然,牺牲一致性并不是要完全忽略数据的一致性,否则数据会很混乱,那么无论系统多么高和分散,系统可用性都没有任何价值。

    牺牲一致性,它不再需要关系数据库中的强一致性,但是只要系统可以实现最终一致性,并考虑到客户的经验,那么最终的一致性时间窗口应该对用户尽可能透明,这是需要的确保“用户感知的一致性”。

    通常,系统的高可用性和最终的数据一致性是通过多次异步复制数据来实现的。“用户感知的一致性”的时间窗口取决于将数据复制到一致状态的时间。

    最终一致

    对于一致性,可以分为从客户端和服务端两个不同的视角。

    从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题。

    从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。

    一致性是因为有并发读写才有的问题,因此在理解一致性的问题时,一定要注意结合考虑并发读写的场景。

    从客户端角度,多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性。

    对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性;如果能容忍后续的部分或者全部访问不到,则是弱一致性;如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。

    从服务端角度,如何尽快将更新后的数据分布到整个系统,降低达到最终一致性的时间窗口,是提高系统的可用度和用户体验非常重要的方面。

    那么问题来了,如何实现数据的最终一致性呢?答案就在事件驱动架构。

    在微服务架构中,每个微服务都有自己私有的数据集。不同微服务可能使用不同的SQL或者NoSQL数据库。尽管数据库架构有很强的优势,但是也面对数据分布式管理的挑战。第一个挑战就是如何在多服务之间维护业务数据一致性;第二个挑战是如何从多服务环境中获取一致性数据。

    最佳解决办法是采用事件驱动架构。其中碰到的一个挑战是如何原子性的更新状态和发布事件。有几种方法可以解决此问题,包括将数据库视为消息队列和事件源等。

    从目前技术应用范围和成熟度看,推荐使用第一种方式(本地事务发布事件),来实现事件投递原子化,即可靠事件投递。

推荐阅读:java架构师指南之架构师的工作流程

0 条评论

请先 登录 后评论
JAVA Q&A
JAVA Q&A

173 篇文章

作家榜 »

  1. JAVA Q&A 173 文章
  2. 江南 1 文章
  3. 伯乐 0 文章
  4. 孤存 0 文章
  5. q21164340 0 文章
  6. 赫敏12 0 文章
  7. 子牙 0 文章
  8. 赫敏 0 文章