读写分离

作者：李鹏博 爱可生 DBA 团队成员，次要负责 MySQL 故障解决和 SQL 审核优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 MaxScale 是由 MariaDB 官网出品的一款开源数据库中间件，其插件是插拔式的，而且能够定制化开发属于本人的插件，应用十分的灵便自在，目前官网提供了例如监控、高可用、读写拆散、防火墙等插件。其中高可用和监控插件相互配合能够实现 MariaDB 的 Failover 、Switchover 、autoRejoin 性能，并在故障转移时能够主动进行数据弥补，不过遗憾的是因为 MySQL 的 GTID 形成形式和 MariaDB 的差异性，目前 MySQL 无奈应用其高可用性能。不过能够应用其读写拆散性能。 提到数据库的读写拆散，其中须要解决的问题就是别离在主从实例上进行读写操作时如何保障在从实例读取的数据的正确性，个别咱们有如下几种做法，比方：提早读取，就是在读取前期待一段时间；转发须要数据正确性较高的查问到主实例；借助 MySQL 自身的半同步复制保障主从数据的一致性，并转发查问到无提早或提早较小的从实例上。第一种做法会人为的拉大查问的返回工夫；第二种则配置及保护起来较为艰难；第三种则看起来"针不戳"的样子。而 MaxScale 的实现形式就是第三种，通过指定读取时可能容忍的最大延迟时间，当从实例延迟时间超过该工夫后，读操作就不会被路由到该节点，如果切实没有可用从节点，读操作就会被路由到主节点。而且 MaxScale 还反对因果读取，通过配置 causal_reads=local 和 causal_reads_timeout 参数来实现，成果就是在从实例进行查问时，如果实例提早较大，会期待 causal_reads_timeout 超时，默认10s，超时后就将查问路由到主节点。当然，也并不是说这种实现形式就是最完满的，思考一种场景，如果所有的从实例都提早较高，在进行查问时没有可用从实例，这时主实例就要承当所有的读写压力，这时候负载会不会将主实例压死也是一个须要思考的问题。所以没有最完满的计划，只有最适宜本人的。接下来让咱们瞅瞅如何配置 MaxScale 实现 MySQL 数据库的读写拆散。 部署拓扑主机名IP角色node410.186.63.88Maxscalenode110.186.61.191MySQL Masternode210.186.61.192MySQL Slavenode310.186.63.64MySQL Slave部署后端 MySQL 一主两从半同步复制，部署步骤略，状态如下： ## 一主两从mysql> show slave hosts;+-----------+---------------+------+-----------+--------------------------------------+| Server_id | Host | Port | Master_id | Slave_UUID |+-----------+---------------+------+-----------+--------------------------------------+| 737716692 | 10.186.61.192 | 3306 | 622227692 | d121bf0f-1922-11ed-86d9-02000aba3dc0 || 534997148 | 10.186.63.64 | 3306 | 622227692 | bb3d53a9-1940-11ed-a059-02000aba3f40 |+-----------+---------------+------+-----------+--------------------------------------+2 rows in set (0.00 sec)## 半同步复制mysql> show global status like 'Rpl_semi_sync_master_clients';+------------------------------+-------+| Variable_name | Value |+------------------------------+-------+| Rpl_semi_sync_master_clients | 2 |+------------------------------+-------+1 row in set (0.00 sec)创立 MaxScale 用户并受权 ...

作者：王娟 爱可生 dble 团队测试成员，次要负责 dble 需要测试，自动化编写和社区问题解答。人狠话不多。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 dble 从 3.20.10 版本开始⽀持单纯的读写拆散性能，能够和分库分表性能离开使⽤。 如何疾速领有读写拆散呢？第一步，筹备好一组 mysql 实 例，并确保这组 mysql 实例的主从复制关系失常。如下应用一主二从的mysql： 主：172.100.9.6:3307 从：172.100.9.2:3307、172.100.9.3:3307 别离到2个从实例上执行 show slave status ，查看复制关系是否失常。 第二步，在 db.xml 配置 mysql 实例。如下： <dbGroup rwSplitMode="1" name="ha_group1" delayThreshold="100"> <heartbeat>show slave status</heartbeat> <dbInstance name="hostM1" password="******" url="172.100.9.6:3307" user="test" maxCon="1000" minCon="10" primary="true"/> <dbInstance name="hostS1" password="******" url="172.100.9.2:3307" user="test" maxCon="1000" minCon="10" readWeight="1"/> <dbInstance name="hostS2" password="******" url="172.100.9.3:3307" user="test" maxCon="1000" minCon="10" readWeight="1"/></dbGroup> 配置 dbGroup 时须要留神以下参数： rwSplitMode： 读操作的负载平衡模式，可选值 0/1/2/3 在进⾏读负载平衡的时候会依据这个配置进⾏0：不做平衡，间接散发到主实例，从实例将被疏忽，不会尝试建⽴连接池，但会有⼼跳连贯 1：读操作在所有从实例中平衡，当所有从实例都不可⽤时，下发语句会报错。 2：读操作在所有实例中平衡。 3：读操作在所有从实例中平衡，当所有从实例都不可⽤时，将语句发往主实例。 delayThreshold：指定主从提早阀值，单位秒，默认 -1 ，表⽰⽆提早 在进⾏读取负载平衡的时候会依据最近⼀次的⼼跳状态以及读库和主库的提早进⾏判断，如果主从复制不⼯作或者复制提早超过 delayThreshold 配置，则认为此节点不适宜进⾏读取，依赖于⼼跳语句为 show slave status 。如果 delayThreshold=-1 那么读负载平衡选取的时候不会进⾏提早检测。 readWeight：节点权重(负载平衡时候使⽤) 负载平衡过程中会查看所有节点的权重是否相等，如果不相等，那么就会依据权重来配置压⼒。该值需是⼤于等于 0 的整数。如果配为 0 表⽰该节点不参加读。需注意，总权重（所有节点权重之和）必须⼤于 0。 如何辨别读节点与写节点？写节点：primary="true"读节点：primary 没配置或者 primary="false" ...

现在，每个开发人员都很熟悉MVC标准体系结构设计模式。大多数的应用程序都是基于这种体系结构进行创建的。它允许我们创建可扩展的大型企业应用程序，但近期我们还听到了另外的一些有关于CQRS/ES的相关信息。这些方法应该被放在MVC中一起使用吗？他们可以解决什么问题？现在，让我们一起来看看CQRS/ES是什么，以及他们都有哪些优点和缺点。CQRS — 模式介绍CQRS（Command Query Responsibility Segregation）是一种简单的设计模式。它衍生与CQS，即命令和查询分离，CQS是由Bertrand Meyer所设计。按照这一设计概念，系统中的方法应该分为两种：改变状态的命令和返回值的查询。Greg young将引入了这个设计概念，并将其应用于对象或者组件当中，这就是今天所要将的CQRS。它背后的主要思想是应用程序更改对象或组件状态（Command）应该与获取对象或者组件信息（Query）分开。下面，将通一张图来说明应用程序中有关CQRS部分的组成结构：Commands（命令）—表示用户的操作意图。它们包含了与用户将要对系统执行操作的所有必要信息。Command Bus（命令总线）：是一种接收命令并将命令传递给命令处理程序的队列。Command Handler（命令处理程序）：包含实际的业务逻辑，用于验证和处理命令中接收到的数据。Command handler负责生成和传播域事件（Event）到事件总线（Event Bus）。Event Bus（事件总线）：将事件发布给订阅特定事件类型的事件处理程序。如果存在连续的事件依赖，事件总线可以使用异步或者同步的方式将事件发布出去。Event Handler（事件处理程序）：负责处理特定类型的事件。它们的职责是将应用程序的最新状态保存到读库中，并执行终端的相关操作，如发送电子邮件，存储文件等。Query（查询）：表示用户实际可用的应用程序状态。获取UI的数据应该通过这些对象完成。下面我们将介绍有关CQRS的诸多优点，它们是：我们可以给处理业务逻辑部分和处理查询部分的开发人员分别分配任务，但需要小心的是，这种模式可能会破坏信息的完整性。通过在多个不同的服务器上扩展Commands和Query，我们可以进一步提升应用程序的读/写性能。使用两个不同的数据库（读库/写库）进行同步，可以实现自动备份，无需额外的干预工作。读取数据时不会涉及到写库的操作，因此在使用事件源是读数据操作会更快。我们可以直接为视图层构建数据，而无需考虑域逻辑，这可以简化视图层的工作并提高性能。尽管使用CQRS模式具有上述诸多的优点，但是在使用前还需要慎重考虑。对于只具有简单域的简单项目，其UI模型与域模型紧密联系的，使用CQRS反而会增加项目的复杂度和冗余度，这无疑是过度的设计项目。此外，对于数据量较少或者性能要求较低的项目实施CQRS模式不会带来显著的性能提升。Event Sourcing — 案例研究有这样一个案例，我们想要检索任何一个域对象的历史状态数据，而且在任何时间都可以生成统计数据。我们想要检查上个月、上个季度或者过去任何时间的状态汇总。想要解决这个问题并不容易。我们可以在特定的时间范围内将额外的数据保存在数据库中，但这种方法也存在一些缺点。我们不知道范围应该是什么样子，以及未来统计数据需要哪些数据项。为了避免这些问题，我们可以每天为所有聚合创建快照，但它们同样会产生大量的冗余数据。Event Sourcing（ES）似乎是目前解决这些问题的最佳方案。Event Sourcing允许我们将Aggregate（聚合）状态的每一个更改事件保存在Event Store的事件存储库中。通过Command Handler将事件写入到事件存储库中，并处理相关的逻辑。要创建Aggregate（聚合）对象的当前状态，我们需要运行创建预期域对象的所有事件并对其执行所有的更改。下面我们将通过一张图来说明这一架构设计方式：下面我们将列举一些使用ES的优点：时间穿梭机：可以及时重建特定聚合的状态。每个事件都包含一个时间戳。根据这些时间戳可以在特定的时间内运行事件或者停止事件。自动审计：我们不需要额外的工作就可以检查出在特定的时间范围内谁做了什么以及改变了什么。这和可以显示更改历史记录的系统日志不同，事件可以告知我们每次更改背后所对应的操作意图。易于引入纠正措施：当数据库中的数据发生错误时，我们可以将应用程序的状态回退到特定的时间点上，并重建当时的应用程序状态。易于调试：如果应用程序出现问题，我们可以将特定事件内的所有事件取出，并逐条的重建应用状态，以检查应用程序可能出现问题的地方。这样我们可以更快的找到问题，缩短调试所需的时间。AggregatesAggregate（聚合）一词在本文中多次被提及，那它到底是什么意思？Aggregate（聚合）来自于领域驱动设计（DDD）的一个概念，它指的是始终保持一致状态的实体或者相关实体组。我们可以简单的理解为接收和处理Command（包含Command Handler）的一个边界，然后根据当前状态生成事件。在通常情况下，Aggregate root（聚合根）由一个域对象构成，但它可以由多个对象组成。我们还需要注意整个应用程序可以包含多个Aggregate（聚合），并且所有事件都存储在同一个存储库中。总结CQRS/ES可以作为特定问题的解决方案。它可以在标准N层架构设计的应用程序的某些层中进行引入，它可以解决非标准问题，常规架构中我们所拿到的是最终状态，在很多情况下，固然当前状态很重要，但我们还需要知道当前状态是如何产生的。CQRS和ES两种概念应该一起使用吗？事实表明，并没有。我们想要统计任何时间范文内的域对象状态，而写库只能存储当前状态。引入CQRS并没能帮助我们解决这一问题。在下一章节中，我们将引入Axon框架，Axon框架时间了CQRS/ES，用于解决某些域对象的一些特定问题，尤其是收集历史统计数据。我们将阐述如何使用Axon框架实现CQRS/ES并实现与Spring Boot应用程的整合。作者：LukaszKucik ，译：谭朝红，原文：CQRS and Event Sourcing as an antidote for problems with retrieving application states,译文：(译)CQRS & EVENT SOURCING — 解决检索应用程序状态问题的一剂良方