分布式中间件
xiaofang233
开源互联网技术追随者、狂热者。
展开
-
从0到1设计分布式海量小文件存储系统
从0到1设计分布式海量小文件存储系统原创 2022-06-14 05:23:03 · 464 阅读 · 0 评论 -
从0到1设计分布式微服务注册中心
从0到1设计分布式微服务注册中心原创 2022-06-14 05:19:17 · 223 阅读 · 0 评论 -
从0到1设计高性能网关
自研高性能网关-架构设计原创 2022-02-07 14:15:15 · 660 阅读 · 0 评论 -
数据同步中间件canal架构设计
主从复制的过程如下图所示:1. Master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events,可以通过show binlog events进行查看);2. Slave(I/O thread)从Master主库拉取binlog数据,将它拷贝到Slave的中继日志(relay log)中;3. Slave(SQL thread)重做中继日志中的事件,更新从库上的数据;原创 2020-03-18 17:34:22 · 362 阅读 · 0 评论 -
Kafka集群原理
Kafka 是一个分布式的、可水平扩展的、基于发布/订阅模式的、支持容错的消息系统。一、集群成员Kafka 使用 Zookeeper 来维护集群成员的信息。每个 broker 都有一个唯一标识符,这个标识符可以在配置文件里指定,也可以自动生成。在 broker 启动的时候,它通过创建临时节点把自己的 ID 注册到 Zookeeper。Kafka 组件订阅 Zookeeper 的 /broker/ids 路径,当有 broker 加入集群或退出集群时,这些组件就可以获得通知。ZooKeeper 两.原创 2020-09-12 18:31:59 · 8280 阅读 · 0 评论 -
Kafka重平衡机制
一、什么是 Rebalance分区的所有权从一个消费者转移到另一个消费者,这样的行为被称为重平衡(Rebalance)。Rebalance 实现了消费者群组的高可用性和伸缩性。消费者通过向被指派为群组协调器(Coordinator)的 broker 发送心跳来维持它们和群组的从属关系以及它们对分区的所有权。所谓协调者,在 Kafka 中对应的术语是 Coordinator,它专门为 Consumer Group 服务,负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。具体原创 2020-09-12 10:51:51 · 2578 阅读 · 0 评论 -
Kafka高性能读写原理
Kafka是高吞吐低延迟的高并发、高性能的消息中间件,在大数据领域有极为广泛的运用。配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。那么Kafka到底是如何做到这么高的吞吐量和性能的呢?一、页缓存技术 + 磁盘顺序写首先Kafka每次接收到数据都会往磁盘上去写,如下图所示。那么在这里我们不禁有一个疑问了,如果把数据基于磁盘来存储,频繁的往磁盘文件里写数据,这个性能会不会很差?大家肯定都觉得磁盘写性能是极差的。没错,要是真的跟上面那个图那么简单的话,那确实这个性能是比较差的。.原创 2020-09-11 09:35:16 · 848 阅读 · 0 评论 -
Kafka可靠数据传递
一、 可靠性保证Kafka 到底在什么情况下才能保证消息不丢失呢?一句话概括,Kafka 只对“已提交”的消息(committed message)做有限度的持久化保证。Kafka 的可靠性保证:Kafka 可以保证分区消息的顺序。只有当消息被写入分区的若干同步副本时,才被认为是已提交的。为什么是若干个 Broker 呢?这取决于你对“已提交”的定义。你可以选择只要 Leader 成功保存该消息就算是已提交,也可以是令所有 Broker 都成功保存该消息才算是已提交。只要还有一个副本是存活的,原创 2020-09-10 19:41:23 · 329 阅读 · 0 评论 -
Kafka副本机制理解
分布式系统中的副本机制所谓的副本机制(Replication),也可以称之为备份机制,通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝。副本机制有什么好处呢?提供数据冗余。即使系统部分组件失效,系统依然能够继续运转,因而增加了整体可用性以及数据持久性。提供高伸缩性。支持横向扩展,能够通过增加机器的方式来提升读性能,进而提高读操作吞吐量。改善数据局部性。允许将数据放入与用户地理位置相近的地方,从而降低系统延时。这些优点都是在分布式系统教科书中最常被提及的,但是有些遗憾的是原创 2020-09-10 11:13:48 · 792 阅读 · 0 评论 -
ShardingSphere源码分析—分布式主键实现
自增主键在传统数据库软件开发过程中,主键自动生成技术是基本需求。各个数据库对该需求也提供了相应的支持,比如 MySQL 的自增键,Oracle 的自增序列等。而在分片场景下,问题就变得有点复杂,我们不能依靠单个实例上的自增键来实现不同数据节点之间的全局唯一主键,这时分布式主键的需求就应运而生。ShardingSphere 作为一款优秀的分库分表开源软件,同样提供了分布式主键的实现机制,今天,我们就对这一机制的基本原理和实现方式展开讨论。ShardingSphere 中的自动生成键方案在介绍 Shard原创 2020-08-20 20:43:02 · 779 阅读 · 0 评论 -
ShardingSphere源码分析—重写JDBC规范
典型的数据库中间件设计方案有2种:服务端代理(Proxy 代理数据库)、客户端代理(Datasource 代理数据源)。不论是代理数据库还是代理数据源,底层都操作了多个数据库实例。不同的是:服务端代理(proxy:代理数据库)中: 我们独立部署一个代理服务,这个代理服务背后管理多个数据库实例。而在应用中,我们通过一个普通的数据源(c3p0、druid、dbcp等)与代理服务器建立连接,所有的sql操作语句都是发送给这个代理,由这个代理去操作底层数据库,得到结果并返回给应用。在这种方案下,分库分表和读写分原创 2020-08-10 15:43:30 · 346 阅读 · 0 评论