redis高性能（2）I/O多路复用
开篇以Get请求为例，处理一个Get请求，需要监听客户端请求（bind/listen），和客户端建立连接（accept），从socket中读取请求（recv），解析客户端发送请求（parse），根据请求类型读取键值数据（get），最后给客户端返回结果，即向socket中写回数据（send）。 下图显示了这一过程，其中，bind/listen、accept、recv、parse和
redis高性能（1）数据结构
redis高性能的原因是什么，好记性不如烂笔头，写个系列把以往笔记写下来，这是开篇。讲之前先把redis为什么是单线程解释一下 redis是单线程吗我们经常能听到别人说：redis是单线程，其实这里主要是指Redis的网络IO（redis 6.0版本支持多线程处理网络I O）和键值对读写（也就是执行命令）是由一个线程来完成的，这也是redis对外提供键值存储服务的主要流程。但redis的其他功能，
Kafka 中的内部主题（Internal Topic）__consumer_offsets。
Kafka 中神秘的内部主题（Internal Topic）__consumer_offsets。 __consumer_offsets 在 Kafka 源码中有个更为正式的名字，叫位移主题，即 Offsets Topic。 老版本 Consumer 的位移管理是依托于 Apache ZooKeeper 的，它会自动或手动地将位移数据提交到 ZooKeeper 中保存。当 Consumer 重启
mysql 普通索引和唯一索引的区别(change buffer)
在不同的业务场景下，应该选择普通索引，还是唯一索引？ 假设维护一个市民系统，每个人都有一个唯一的身份证号，而且业务代码已经保证了不会写入两个重复的身份证号。如果市民系统需要按照身份证号查姓名，就会执行类似这样的 SQL 语句： 1select name from CUser where id_card = 'xxxxxxxyyyyyyzzzzz'; 所以，你一定会考虑在 id
mysql InnoDB架构
在介绍之前先来看看InnoDB的架构图： InnoDB内存结构主要由两部分组成：Buffer Pool和 Redo LogBuffer。 1.Buffer Pool缓冲池作用BufferPool 作为内存中的一块区域，在Innodb访问表的时候会将数据页和索引页缓存到缓冲池中。Innodb不管是主键索引还是辅助索引都是以页为单位存储在磁盘空间中的。 当Innodb访问某个页的数据时候，会先把这个
kafka的 groupid 与 auto.offset.reset
通常我们消费kafka数据的时候都会设置两个参数： 123Properties props = new Properties();props.put("group.id", groupId);props.put("auto.offset.reset", autoOffset); kafka-0.10.1.X版本之前: auto.offset.reset
kafka消费者组重平衡能避免吗
消费者组重平衡能避免吗? 重平衡，也就是 Rebalance， 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。 所
mysql三大日志
日志是 mysql 数据库的重要组成部分，记录着数据库运行期间各种状态信息。 mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。作为开发，我们重点需要关注的是二进制日志( binlog )和事务日志(包括redo log 和 undo log )，本文接下来会详细介绍这三种日志。 binlogbinlog 用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的