0.11版本之前依赖于HW实现副本同步备份，0.11之后通过Leader epoch实现副本同步备份。 两个概念： LEO：log end offset，日志末端位移，记录了该副本底层日志下一条消息应存放的位置。 HW，高水位值，小于等于HW的消息是被认为已经备份的。 [0, 7]的消息是已经完全备份，[8, 15)的数据为尚未完全备份的。 kafka中所有的副本都保有自己的HW值和LEO值，

kafka中的topic是逻辑上的概念，而真正存储消息的是分区，更具体点来说是分区中的segment，每个分区可分为多个segment，存储的消息称为日志。 1、LogSegment一个partition分区拥有多个logsegment，kafka日志追加是顺序写入的，把分区分为多个日志段可减小日志文件的大小，在进行日志删除和数据读取的时候也可以快速定位。需要注意的是只有活跃的日志段拥有文件的写

1、消费者与消费组消费组是kafka提供的可扩展且具有容错性的消费者机制，同一个消费组的消费者共有一个groupId，一个分区只能被同一个消费组中的一个消费者消费。 消费组解决了什么问题： 消费模式灵活，假设三个消费者订阅了一个主题，当使用三个消费组时，每个消费组有一个消费者，利用分区在不同消费组间共享的特性，就实现了发布订阅(广播)模式；当把这三个消费者放在一个消费组中时利用分区在消费组成员间

1、生产者1.1、batch生产者在发送消息时不会将每一条消息都单独发送到broker中，而是采取了批量发送以此减少网络请求次数和磁盘IO次数，消息会先发到缓冲区，这个缓冲区的大小是可配置的，在缓冲区中将消息进行分批，缓冲区大小默认为32M，当缓冲区使用完后消息的追加将会被阻塞直到有空闲的区域。batch.size: 此参数配置发送到同一分区的批量提交的数据的大小，默认为16k，当消息积压到这个

1、前言考虑下面几个条件下如何提升kafka的消费速度 消息要求严格有序，如chat聊天消息 业务处理速度慢，如处理一条数据需要100ms 分片不合理，如有的分区很闲，有的分区消息数量积压 2、解决方案1、顺序问题关于消息消费时存在先后顺序问题，在chat聊天系统思考之一中已经加以说明。具体实现大致为对同一会话、帖子Id等维度放入同一分区中，如使用Id % 分区数，如下图：上面的解决方案是将同

前言之前有段工作经历涉及到了chat相关，而消息的发送 -> 存储 -> 消费是由不同的团队负责的，因此消息如何再多个团队之间流通、以及通过什么介质传递都是需要考虑的问题。 之前我负责过一些消息消费的相关工作，消息发送团队将消息推送到kafka之后，由我们去订阅topic并消费对应的分区，拿到消息之后做对应的消息类型解析、消息发送双方可见性分析、接收方未读数、推送等业务处理。本文旨在记

1、参数概览依赖github.com/ddliu/go-httpclient进行http接口请求依赖github.com/antlabs/pcurl解析curl 输入参数： -c，concurrency，并发数，启动协程数 -n， totalNumber，单个协程发送的请求个数 -u，curl字符串 -p，如果不使用-u，可以将curl地址放在文件中，使用-p传入curl文件地址 -e，expe

关于构建内容审核体系思考对于很多企业尤其是互联网内容企业如大型论坛、直播等来说，内容安全可以说是企业的生死线。内容审核能够甄别并过滤出涉黄、暴恐、违禁、不良价值观、广告等风险内容，确保企业平台上的信息符合法律法规和运营规则，从而保障企业的内容安全‌。 1 服务划分 业务层：产品的使用者，包括C端和B端用户，其中B端用户一般代表着商家，其发布的内容影响力相对来说会比较大，也是内容审核的重点。 接入

cachego 内存模型原理剖析cachego github地址cachego 是一个拥有分片机制的轻量级内存缓存库，API 友好，支持多种数据淘汰机制，可以应用于所有的 GoLang 应用程序中 功能特性 以键值对形式缓存数据，极简的 API 设计风格 引入 option function 模式，简化创建缓存参数 提供 ttl 过期机制，支持限制键值对数量 提供 lru 清理机制，提供 lfu

cachego 分片、上报、GC与数据加载机制原理cachego github地址 为减小锁之间的竞争，cachego引入了分片机制，将key分散到多个sharding中，减低锁冲突概率加速索引。 sharding机制可与lru、lfu、standard模式丝滑结合，以实现cache中所有sharding内存模型都是指定的某种类型。 reporter 上报功能，支持上报hit次数、miss次数