Kafka是面向海量消息设计的，一个Topic下的消息会非常多，单机服务很难存得下来。一个典型的MQ系统，会将消息消息由生产者发送到MQ进行排队，然后根据一定的顺序交由消息的消费者进行处理。最后：Kafka集群中的这些Broker信息，包括Partition的选举信息，都会保存在额外部署的Zookeeper集群当中，这样，kafka集群就不会因为某一些Broker服务崩溃而中断。Kafka的基础工

然后，Sender对读取出来的消息，会以Broker为key，缓存到一个对应的队列当中。但是如果消费者没有提交Offset，Broker就会认为这个消息还没有被处理过，就会重新往对应的消费者组进行推送，不过这次，一般会尽量推送给同一个消费者组当中的其他消费者实例。例如如果在部署消费者时，如果我们的服务器配置不一样，就可以通过定制消费者分区器，让性能更好的服务器上的消费者消费较多的消息，而其他服务器

在搭建Kafka服务时，在server.properties配置文件中通过log.dir属性指定了Kafka的日志存储目录。实际上，Kafka的所有消息就全都存储在这个目录下。这些核心数据文件中，.log结尾的就是实际存储消息的日志文件。大小固定为1G(由参数 log.segment.bytes参数指定)，写满后就会新增一个新的文件。一个文件也成为一个segment文件名表示当前日志文件记录的第一

Kafka将状态信息保存在Zookeeper中，这些状态信息记录了每个Kafka的Broker服务与另外的Broker服务 有什么不同。通过这些差异化的功能，共同体现出集群化的业务能力。这些数据，需要在集群中各个Broker 之间达成共识，因此，需要存储在一个所有集群都能共同访问的第三方存储中。Kafka的整体集群结构：Kafka的集群中，最为主要的状态信息有两个：在多个Broker中，需要选举出

Sharding-JDBC是2015年开源的，早期的定位就是一个分布式数据库的中间件，而在它之前有一个MyCat的产品。使用其实不难的，关键是要找对方法，网上文章千千万，版本也是千奇百怪，初学者看的配置越多可能越不理解，ShardingSphere每个大版本的配置项都有很多改进，所以笔者建议理解每种策略存在的意义，解决问题的思想才是更有价值的。主要是用在压测的场景，比如说你的业务开发完了，需要测试

key 是查询的语句，value 是查询的结果。我们知道由于MySQL是开源的，他有非常多种类的客户端：navicat,mysql front,jdbc,SQLyog等非常丰富的客户端，包括各种编程语言实现的客户端连接程序，这些客户端要向mysql发起通信都必须先跟Server端建立通信连接，而建立连接的工作就是有连接器完成的。开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果

集群模式下配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面有一个数据 就是 A 的值，Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个server。2、epoch表示ZooKeeper服务器的逻辑时期（logical epoch），它是一个相对时间的概念，用于区分不同的Leader选举周期。全局可线性化(Linea

ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议，ZAB是Paxos算法的一种简化实现。。（当 Leader 服务可以正常使用，就进入消息广播模式，当 Leader 不可用时，