吉林市做网站哪家好,网络营销策略理论有哪些,推广网站建设,本地php网站搭建为什么要数据分发
微服务中#xff0c;每个服务都有独立的数据源#xff0c;这使得数据同步成为难题。 拉模式or推模式#xff1f;
拉模式存在的问题 由于网络延迟#xff0c;拉取的数据不一定是最新的 如果频繁向另一服务拉取数据#xff0c;会给服务造成压力#xf…为什么要数据分发
微服务中每个服务都有独立的数据源这使得数据同步成为难题。 拉模式or推模式
拉模式存在的问题 由于网络延迟拉取的数据不一定是最新的 如果频繁向另一服务拉取数据会给服务造成压力如果拉取频率过低数据就会同步不及时。 推模式存在的问题
如何保证数据的一致性或者说如何保证数据分发的事务性 数据一致性分发
事务消息盒子事务性发件箱
本质是利用本地事务的事务性保证了消息分发的最终一致性。 在数据库中新开一张发件表OUTBOX table用于存放要分发的数据相关信息。 在往本地表和发件表一起写数据的时候开启本地事务如果成功则一起提交出错则一起回滚。 实现消息中继器MessageRelay定期拉取OUTBOX table中的数据并发送到对应服务。 如果成功则数据分发成功否则记录重试次数实现至少发送一次的功能接收数据的服务可能需要做幂等处理若重试次数达到阈值分发失败需人工干预。 Killbill Common Queue
是对事务性发件箱的开源实现。 上图中灰色框框起来的部分就是组件对事务性发件箱的核心实现 事件分发线程DispatcherThread会从数据队列DBQueue中拿一个事件Event并将这个事件写入到事件表中后续这个事件扔给事件总线EventBus处理。 同一节点的事件总线EventBus拿到事件分发线程分发的事件EventBus再将事件分发到对应的Handler由Handler处理事件。 如果事件处理成功则标记成功失败则记录失败次数累计到阈值标记失败由人工干预处理 每一个节点事件分发线程都只负责自己节点分发的事件 reaper机制
事件分发线程有多个假如在运行过程中有事件分发线程挂了那这个线程中的事件怎么处理呢
Killbill Common Queue引入了reaper机制reaper会监控是否有已经写入数据库表但长时间未处理的事件如果发现了就讲这个事件收割后续这个事件将由自己处理。
收割机机制保证了killbill common queue的高可用性相当于保证了事务性发件箱中的Message Relay的高可用性。 EventBusPersistentBus
EventBus实现了事件性发件箱的MessageRelay功能。
此外EventBus的机制为事件机制一开始会在EventBus中注册handlerhandler绑定需要处理的事件当EventBus中收到event时就会发送给绑定该事件的handler处理。 async-event
是公司的一个组件使用了hyperf的事件机制实现了事务性发件箱的功能。 以下为核心功能dispatch实现 在45-48行中方法遍历了所有监听器listener把监听器名、事件名、事件中的数据存到发件表中。
在try中调用listener去处理事件如果处理成功则将发件表中的事件状态标记为完成。
在catch中如果处理事件出错就会记录重试次数。 async-event中存在一个定时任务每十分钟拉取未处理成功的待处理的事件然后丢给retry方法重试 retry方法就是将事件进行重试先反序列化事件在将事件丢给对应的监听器处理如果处理完成就标记完成否则记录重试次数如果重试次数达到阈值则标记失败。 CDC-变更数据捕获 Change Data Capture, CDC 每个数据库在变更数据是都有事务日志或提交日志。启动可以一个服务Transaction log miner用来订阅这个日志当捕获到数据变更时就将数据变更内容发送给mq如果异常会重发至成功。 变更数据捕获常用作于 数据迁移常用于数据库备份、容灾等 数据分发将一个数据源分发给多个下游常用于业务解耦、微服务 数据采集将分散异构的数据源集成到数据仓库中消除数据孤岛便于后续的分析。 相应开源项目 阿里 CanalGitHub - alibaba/canal: 阿里巴巴 MySQL binlog 增量订阅消费组件 Redhat DebeziumGitHub - debezium/debezium: Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/browse/DBZ. Zendesk MaxwellGitHub - zendesk/maxwell: Maxwells daemon, a mysql-to-json kafka producer Airnb SpinalTapGitHub - airbnb/SpinalTap: Change Data Capture (CDC) service FIink -CDC 内部组件实现https://git.kkgroup.cn/brd/data-transfer-service 下面是cannal的工作原理
MySQL主备复制原理 MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events可以通过 show binlog events 进行查看) MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log) MySQL slave 重放 relay log 中事件将数据变更反映它自己的数据
canal 工作原理 canal 模拟 MySQL slave 的交互协议伪装自己为 MySQL slave 向 MySQL master 发送dump 协议 MySQL master 收到 dump 请求开始推送 binary log 给 slave (即 canal ) canal 解析 binary log 对象(原始为 byte 流) CQRS-命令查询职责分离
一种设计模式看了很多资料感觉有点高深了简单来说就是 命令CUD会改变数据的操作 查询R不会改变数据
CQRS将命令和查询划分为两个不同的对象CQRS使用分离的接口将数据查询操作(Queries)和数据修改操作(Commands)分离开来这也意味着在查询和更新过程中使用的数据模型也是不一样的。这样读和写逻辑就隔离开来了。
mysql的读写分离是在数据库层进行的而CQRS也可以理解成一种读写分离但是读写分离操作是在应用层进行的。 内部实现es同步组件 https://git.kkgroup.cn/brd/elasticsearch-service
在写数据库时将数据聚合并同步到es中在查询聚合数据时到es查询。 要思考的问题 分发过程中要确保一定发送如果发送失败就会重试。但由于网络抖动等原因无法判断是否发送成功会导致消息可能会发送多次。 由于会存在消息发送多次的情况消费端就要做好消息去重或幂等机制 需要考虑是否有顺序性问题。比如两条消息的消费需要具备顺序性或使用其他方式规避竟态并发带来的困扰。没遇到过具体情况 业务使用时需要理解最终一致性的最终俩个字设计上需要容忍获取到中间态的数据。没遇到过具体情况 参考资料
简书KillBill框架介绍
CSDN如何解决微服务的数据一致性分发问题
博客园命令查询职责分离模式CQRS
