partition

Kafka基于磁盘做的数据存储，如何实现高性能、高吞吐、低延时？ Reference： http://searene.me/2017/07/09/Why-is-Kafka-so-fast/ and https://queue.acm.org/detail.cfm?id=1563874 . 顺序读写   Kafka将消息记录持久化到本地磁盘中，实际上不管是内存还是磁盘，快或慢关键在于寻址的方式，磁盘分为顺序读写与随机读写，内存也一样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢，但磁盘的顺序读写性能却很高。   Kafka使用磁盘顺序读写来提升性能，Kafka的message是不断追加到本地磁盘文件末尾的，而不是随机的写入，这使得Kafka写入吞吐量得到了显著提升 。每一个Partition其实都是一个文件 ，收到消息后Kafka会把数据插入到文件末尾。   这种方法不能删除数据 ，所以Kafka是不会删除数据的，它会把所有的数据都保留下来，每个消费者（Consumer）对每个Topic都有一个offset用来表示 读取到了第几条数据 。 两个消费者，Consumer1有两个offset分别对应Partition0、Partition1（假设每一个Topic一个Partition）；Consumer2有一个offset对应Partition2

消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。 1.1 Kafka的特性: - 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 - 可扩展性：kafka集群支持热扩展 - 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 - 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） - 高并发：支持数千个客户端同时读写 1）每个service里面的kafka consumer数量都小于对应的topic的partition数量，但是所有服务的consumer数量之和等于partition的数量，这是因为分布式service服务的所有consumer都来自一个consumer group； 2） 如果来自不同的consumer group就会处理重复的message了。同一个consumer group下的consumer不能处理同一个partition，不同的consumer group可以处理同一个topic，那么都是顺序处理message，一定会处理重复的。

MapReduce Shuffle 和 Spark Shuffle 区别看这篇即可 Shuffle的本意是洗牌、混洗的意思，把一组有规则的数据尽量打乱成无规则的数据。而在MapReduce中，Shuffle更像是洗牌的逆过程，指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据，以便reduce端接收处理。其在MapReduce中所处的工作阶段是map输出后到reduce接收前，具体可以分为map端和reduce端前后两个部分。 在shuffle之前，也就是在map阶段，MapReduce会对要处理的数据进行分片（split）操作，为每一个分片分配一个MapTask任务。接下来map会对每一个分片中的每一行数据进行处理得到键值对（key,value）此时得到的键值对又叫做“中间结果”。此后便进入reduce阶段，由此可以看出Shuffle阶段的作用是处理“中间结果”。 由于Shuffle涉及到了磁盘的读写和网络的传输，因此Shuffle性能的高低直接影响到了整个程序的运行效率。 MapReduce Shuffle Hadoop的核心思想是MapReduce，但shuffle又是MapReduce的核心。shuffle的主要工作是从Map结束到Reduce开始之间的过程。shuffle阶段又可以分为Map端的shuffle和Reduce端的shuffle。

走zabbix的1.6版本开始测试，1.8的版本开始线上使用，线上使用过1.9、2.0、2.2、3.0、4.0的版本，使用或是测试过zabbix1.6之后的所有版本。个人也有之前的SA转变为DBA，就zabbix的运维走数据库层面有一些自己的心得，希望对读者有所帮助。 1：MySQL版本推荐 MySQL5.7及以上版本，便捷的在线DDL方便zabbix的快速升级 链接数据库方式：zabbix的server、proxy、MySQL数据库尽量使用域名方式连接，方便进行故障切换。 2：zabbix数据库的授权 读写权限，用作zabbix自身访问： grant all privileges on zabbix. to 'zabbix'@'1.1.1.1' identified by 'zabbix'; 只读权限，用作二次开发只读zabbix数据库： grant SELECT on zabbix. to 'zabbix_ro'@'1.1.1.1' identified by 'zabbixro'; 3：MySQL配置文件需要调整的几个重要参数 innodb_log_files_in_group = 16 innodb_log_file_size = 1G innodb_file_per_table = 1 max_allowed_packet = 64M back_log = 1024

Topic 主题，从逻辑上讲一个Topic就是一个Queue，即一个队列；从存储上讲，一个Topic存储了一类相同的消息，是一类消息的集合。比如一个名称为trade.order.queue的Topic里面存的都是订单相关的消息。 Partition 分区。分区是存在于服务端，内部保持顺序、且顺序不可变更的一个队列，用于存储消息。分区可能不应该出现在消息领域内，在使用消息中间件发送和消费时，实际上用户是感受不到分区这个概念的。下面这幅图便于大家去理解分区： 一个Topic存储消息时会分为多个Partition，每个Partition内消息是有顺序的。至于为什么需要将Topic划分成按照Partition存储，在以后设计和实现部分会解释。 Producer 生产者，消息的生产方，一般由业务系统负责产生消息。 Producer负责决定将消息发送到哪个Topic的那个Partition。 Consumer 消费者，消息的消费方，一般是后台系统负责异步消费消息。 Consumer订阅Topic，消费Topic内部的消息。 Broker 消息的存储者，一般也称为Server，在JMS中叫Provider，在RocketMQ（阿里开源的消息中间件）中叫Broker。 NameServer NameServer其实不是消息中间件的概念了

1、kafka的HA机制：副本机制+消息同步+leader选举。每个topic有多个partition，每个partition又有多个副本，这些副本当中也存在不同的角色，leader、follower。producer和consumer都只跟leader进行交互，leader进行读写操作。leader负责将消息写进本地log当中，follower去leader上pull拉取数据，将数据同步到本地log当中。当leader挂了的时候，就利用zookeeper重新选出一个leader即可。 　　其中，kafka将所有的partition均匀分布在集群中的broker上，所有的Replica副本也均匀分布在集群中的broker上，这样做主要是保证负载均衡和容错能力。因为所有的分区和副本都在一个broker上，那样这个broker挂了，数据也就都丢失了。实现这个均匀分布，使用的是一种算法。主要就是用求余数的运算。 　　Kafka分配Replica的算法如下： 　　1.将所有Broker（假设共n个Broker）和待分配的Partition排序 　　2.将第i个Partition分配到第（i mod n）个Broker上 　　3.将第i个Partition的第j个Replica分配到第（(i + j) mode n）个Broker上 总之，kafka的健壮性主要来源其强大的副本策略。 2