Skip to main content

· 6 min read

Redis 当前支持 aof 和 rdb 这两种持久化方式。 有些对 Redis 不是特别的了解同学误解持久化是读写数据也会到磁盘。这里辟谣一下:

Redis 读写都是全内存的, 持久化数据只是作为磁盘备份, 实例重启或者机器断电的时候可以从磁盘加载到内存

由于本篇博客主要是为了分析 4.0 版本的 rdb 和 aof 混合存储的实现,所以不会详细介绍 rdb 和 aof。如果有想进一步了解可参考 《Redis 设计与实现》 一书。

· 8 min read

上一篇介绍了 <Redis-4.0 module实现>,同时也提到 redis 4.0 一个比较大的改动就是 psync 优化, 本篇会介绍这个优化的部分。

在 2.8 版本之前 redis 没有增量同步的功能,主从只要重连就必须全量同步数据。如果实例数据量比较大的情况下,网络轻轻一抖就会把主从的网卡跑满从而影响正常服务,这是一个蛋疼的问题。2.8 为了解决这个问题引入了 psync (partial sync)功能,顾名思义就是增量同步。

· 8 min read

直到今天为止 (2017-01-17) Redis 4.0 已经发布了两个 rc 版本, 相比于上个版本(3.2),这个版本的改动应该说是巨大的。主要有以下几个点:

  • 增加了模块的功能, 用户可以自己扩展命令和数据结构
  • psync 优化,避免主从切换过程需要重新全量同步
  • DEL, FLUSHALL/FLUSHDB异步化,不会阻塞主线程
  • RDB-AOF 混合持久化
  • 新增 MEMORY 命令
  • 集群兼容 NAT / Docker

每个功能都很值得期待,本篇博客会重点来介绍 Redis 的模块功能。

· 5 min read

知道或者熟悉 kafka(不是写小说的那个卡夫卡), 那么一定知道它有 producer 和 consumer 这两种角色。producer 用来生产消息,consumer 用来消费消息。

1) 可用性

下面是来自维基百科的解释:

在一个给定的时间间隔内,对于一个功能个体来讲,总的可用时间所占的比例

比如我们以年为单位来量化一个服务的可用性。假设一年 365 天当中有 364 天服务是正常服务的,那么我们就说这个服务的可用性是 364/365(用计算器口算了一下约 99.72%)。

我们常用几个 9 来衡量一个服务的可用性,两个 9 就是 99.99%,三个 9 即 99.999%, 四个 9 即 99.9999% ... 以此类推。

可用性每年宕机时间
99.9%8 个小时
99.99%1 个小时
99.999%5 分钟
99.9999%30 秒

2)消费者的可用性

一般来说 producer 是嵌入到业务程序,那么可用性就由业务程序来保证。而 consumer 一般就是以独立的程序存在,那么就要自己来保证。

所以想让 consumer 做到 99.99% 以上的可用性,意味着一年内服务挂掉的时间不能超过一个小时。假设我们没有实现一些高可用的机制,部分 consumer 在半夜挂了,而你(或者运维)刚好干完一些不可描述的事情之后倒头大睡而没有注意到报警,这个系统的可用性就达不到要求。

当前 scala, java, golang, c 版本的做法都是监听 group 的 consumer 列表,如果有 consumer 进入或者退出都会触发重新分配分区,把分区均衡到各个 consumer。所以理论上我们 php 版本也可以这样做。现在已有的开源里面有 kafka 和 zookeeper 的客户端扩展和依赖库,但没有实现自动平衡的逻辑(也可能是我没看到), 所以这部分需要自己来做。

3) 尴尬的 php

这里必须先承认 php 是世界上最好的语言。

php 要实现 consumer 的高可用有三中选择:

  • 开启 php 线程扩展
  • c 实现 group 逻辑
  • 不使用多线程,边消费边监控

第一种方案,因为我们线上 php 环境都是没有打开线程安全, 所以如果要使用这个扩展需要重新编译 php 核心代码并重启所有服务,这个基本是无法接受的。

第二种方案,可以不用重新编译 php, 性能好。但开发成本比较高,风险大。

第三种方案, 纯 php 实现,代码简单可控,但性能会比较差一些。

最后我们选择了第三种方案,单进程空跑(只拉消息不处理)的性能是 7w+/s, 这个是可以接受的。

4) 功能和代码说明

  • 分区变化时可自动重新分配分区
  • 消费进程退出或者加入时可自动重新分配分区
  • 自动管理 offset
  • 兼容标准的 consumer group 路径,方便已有的工具监控
  • 接收用户信号,平滑进入和退出 group
  • 允许冗余的消费进程作为备份

github 地址: https://github.com/meitu/php-kafka-consumer

当前我们公司(美图)内部已经有不少业务已经在线上使用,当前版本已经比较稳定。

5)最后

前一段时间发现线上 consumer 内存不断上升的情况,经排查,最终定位并验证是依赖库的 php-zookeeper 有内存泄漏。现在已经反馈以及合并到社区的 master, 具体见 pr

如果使用 release(建议) 版本的 php-zookeeper, 需要手动 patch 这个 bug,否则会造成内存泄漏。

如果有问题或者任何意见,欢迎 issue 或者 pr。

· 7 min read

一年即将过去,翻了一下博客发现更新频率比月经还来得稀疏,内疚到前列腺都萎缩了。

转入正题,本篇博客主要是分享一个自己日常用的比较多工具 tcpkit, 该工具用途主要是用来抓包和快速的分析数据包。

代码地址: git-hulk/tcpkit

· 12 min read

beanstalkd 是单机版本的任务队列服务, 任务队列跟消息队列在使用场景上最大的区别是: 任务之间是没有顺序约束而消息要求顺序(FIFO),且可能会对任务的状态更新而消息一般只会消费不会更新。 类似 Kafka 利用消息 FIFO 和不需要更新(不需要对消息做索引)的特性来设计消息存储,将消息读写变成磁盘的顺序读写来实现比较好的性能。而任务队列需要能够任务状态进行更新则需要对每个消息进行索引,如果把两者放到一起实现则很难实现在功能和性能上兼得。在美图内部选型上,如果是异步消息模型一般会选择消息队列,比如类似日志上报,抢购等。而对于需要延时/定时下发或者修改状态任务则是使用任务队列。

· 9 min read

DBA 发现同一组 Redis 从库中有实例 QPS 比较高,对比发现只是其中一个从库偏高而其他从库是正常的,分布如下:

image

那么问题就是: 「为什么会 QPS 不均匀?」, 由于我们先上 php 业务都是长连接,QPS 不均匀应该是连接数不均带来的。然后让运维大侠统计了一下四个实例的连接数,发现确实请求量跟连接数是成线性正相关的。

· 5 min read

作为一个不合格的开发人员多多少少都被 OOM(Out of memory) x 过,只是一般大家对于为什么被选中,可能没太考究。

简单来说之所以会出现 OOM, 就是已分配的虚拟内存大于物理内存和 Swap 分区大小,导致需要内存无法分配。如果 overcommit = 2, 在申请虚拟内存时,如果超过限制的内存比例 + Swap 空间会直接返回失败,只要分配虚拟内存不超过物理内存,也就不会有 OOM。

· 6 min read

春节前几天运维大侠说要扩容 Redis 从库但同步一直失败,看日志发现在做 bgsave 的时候一直失败。 日志如下:

[41738] 04 Feb 11:16:39.859 * Full resync requested by slave.
[41738] 04 Feb 11:16:39.859 * Starting BGSAVE for SYNC
[41738] 04 Feb 11:16:39.860 # Can't save in background: fork: Cannot allocate memory
[41738] 04 Feb 11:16:39.860 * Replication failed, can't BGSAVE

从日志可以看到 fork 的时候内存分配失败导致 bgsave 无法成功,那就是可用内存不足?

· 4 min read

长连接可以减少建立连接的过程, 使用长连接可以提高服务的性能。php 很多扩展都支持长连接,如 redis, memcache, mysql 的主流扩展都支持。

我们知道长连接就是一次建立连接,使用之后不会马上释放,而是把这个连接放到连接池。那么引发的一个问题就是,我们下次使用时如何知道这个连接是否已经被关闭。