前言

2019年的RedisConf比以往时候来的更早一些，今年会议时间是4月1-3号，仍然是在旧金山鱼人码头Pier 27。恰逢今年是Redis第10周年，规模也比以往大一些，注册人数超过1600人，总共有80个议题，除了RedisLabs外还有很多云厂商和Redis用户带来分享，今年也是阿里云首次在RedisConf进行分享。

Agenda

会议总共三天，第一天是Training Day，主要是作者开场加RedisLabs的培训课程，今天的agenda如下图：

会议记录

Breakfast

注册过程很简单，输入自己的名字就可以打印入场券，我们到的比较早就先上来吃早餐。

早餐还不错，有各种水果和面包蛋糕，还有咖啡和茶，终于有口热水喝了，4月初的旧金山还是挺冷的，我还裹着羽绒服但是美帝人民已经有短袖短裤上阵的了。

Opening Session

在课程开始之前，Redis作者antirez先来开场，和Redis的开发一样依然是随性的风格，没有准备PPT直接现场演示。

作者开场对Redis的介绍比较简单，像一些数据结构和基础命令的使用，也是为了照顾到大多数的受众，来参会的也有不少刚刚接触Redis的用户。比较重要的是作者认为Redis现在已经不止是Cache了，因为具备persistence持久化和replication复制功能，已经是一个完备的Database，这也是今年会议的主题之一。

期间有个小插曲，在介绍list时作者忘记了RPOPLPUSH这个命令要怎么写，现场打开源码，vi了一把server.c才搞定，哈哈，毕竟Redis发展到现在已经10年，有6种数据结构和上百个命令，有些命令也非常复杂。

之后和作者做了下简单交流，作者很高兴这次我们过来参加RedisConf，对前年云栖大会的中国之行印象深刻，也称赞了阿里云对Redis社区的贡献，不过由于昨天才到旧金山，时差还没倒过来比较疲惫，很快就回酒店休息了。

先来张合影镇楼，哈哈。

Training

之后是RedisLabs的课程，我们挑了几个去听，整体听下来的感觉比较基础，还是偏向于入门的介绍。

Redis as a Primary Data Store

这个课程主要是讲如何使用事务来构造各个key的关系，毕竟Redis是key-value型数据库，要同时修改多个有关系的key就会有并发问题，此时就要利用事务来保证原子性。

Redis Clustering

关于集群的一些简单介绍，比较重要的是RedisLabs在社区Cluster上也做了一套Proxy来方便用户接入，Proxy是今年超热门的话题。

Streaming Architectures

Redis 5.0引入了Streams数据结构，用来对标kafka，这个课程对Streams做了下科普，一些命令的使用演示，演讲人Itamar也是Github上的老朋友了，很风趣幽默，他说已经告诉了好多人这次RedisConf我们会来，还邀请他的朋友明天去参加我们的session，一直称我们是amazing guys哈哈。

课程期间作者从Twitter上发来消息，问我们中午有没有时间一起for Redis internals talk，于是乎约了午饭时间来讨论。

Lunch & Redis internals talk

今天的午餐比较简陋，就是便当，有火鸡三明治、牛肉汉堡等，但是都是冷的。。。中国胃还是吃不惯啊。随便拿了个火鸡三明治，一边吃着一边和作者讨论了。

作者说上次来杭州的时候玩的很开心，逛了西湖和灵隐寺，在灵隐寺吃了素斋很不错，尤其是豆腐很好吃，意大利的豆腐都是硬的，龙井茶也很好喝，上次买的已经喝完了，意大利也没有卖的，比较遗憾这次没给他带份龙井当礼物，下次来中国多买点哈哈。同时也邀请我们去意大利玩，自己平时是在西西里住，但是他在佛罗伦萨有房子，如果我们去可以住他家里，聊到西西里的美丽传说大家会心一笑哈哈，还有电影教父，来自西西里的黑手党，作者自嘲自己家乡的人在世界各地制造麻烦。

午饭闲聊完开始讨论正事，作者重新启动了threaded-io分支的开发，也就是网络读写多线程（前一个星期还在博客上说这个feature短期不打算开发，结果现在又开始了，真是随性哈），因为读写网络的read/write系统调用在Redis执行期间占用了大部分CPU时间，如果把网络读写做成多线程的方式对性能会有很大提升。现在已经实现了第一版，write side也即回复客户端这部分已经完成了，并且去掉了主线程和IO线程之间的互斥锁，采用busy loop的形式来等待io线程工作结束，这部分能够有50%的性能提升，架构图如下：

Redis采用的是事件驱动模型，执行逻辑仍然是单线程串行执行模式，待所有命令执行完成之后，把客户端的reply分发给多个IO线程，等IO线程回写客户端完成后再进行下一轮事件循环。

write side采用这种模式提升很明显，现场测试性能可以提升50%，但是比较奇怪的是read side采用同样模式却没有任何提升，于是现场code review了下：

代码逻辑上没有发现什么明显的问题，会后再checkout这个分支仔细看下。其实目前社区threaded-io分支的架构设计和我们阿里云在做网络多线程的早期版本比较像，整个逻辑read-work-write仍然串行，只是把read/write多线程化，这样对Redis原来的逻辑改动较小，我们后来进行了更彻底的拆分，read/work/write流水线化，不同客户端的read/work/write可以并行，但是仍然保留work的串行逻辑不破坏Redis的执行语义，设计详见 https://www.atatech.org/articles/112918 ，这个设计思路也和作者进行了交流，不过Redis作为一个开源项目，逻辑简单、可读性强还是占了比较高的优先级，他不想把Redis做的太复杂，所以还是只做read/write的并行化，尽量的减少read/write的整体时间而不是read/work/write的流水线，内部使用和开源项目还是有不同的侧重点。

来个硬广：阿里云Redis多线程性能增强版已经上线售卖，欢迎大家使用。

另外就是关于Proxy，就在昨天刚刚放到Github上，目前只是一个demo比较简单，只有一些基础功能，但是这个项目不是作者自己开发，而是交给了Fabio，一个在意大利的小伙伴，我们也对阿里云的Proxy做了介绍，我们的Proxy已经很成熟了，也实现了很多高级功能比如：多DB、block类命令、PUBSUB、Lua脚本、事务、多key命令支持等，作者很有兴趣问我们有没有开源，由于使用了一些内部类库目前还没有开源，不过后面还是有开源的计划的，作者也邀请我们参与到社区Proxy的开发中。

Proxy项目地址： https://github.com/artix75/redis-cluster-proxy