会议议程

Day 0是Training Day，之后的两天就都是正式的会议session了，下面图是Day 1 session day的所有议程。早上会有一个breakfast，之后就是keynotes，主要是redislabs的新特性发布，毕竟是会议举办方嘛，然后是邀请的大客户出来站台，后面会议记录会详细介绍下。接着是各个session的演讲时间了，每个session差不多45分钟时长，会有5-6个session同时进行，所以我们是按需求和兴趣挑选着来听的。所有session结束后，会有一个meetup，大家可以互相做个交流。

会议记录

早餐比较简单，汉堡和咖啡，苹果不错~

上午的keynotes开场是Redislabs的CEO宣传自己公司取得的成就，目前已经进入Forrester Wave象限的leader角色，结束后他邀请作者上来讲Redis 5.0规划的feature。

作者开场先说明了5.0最重要的feature是Redis Stream，在之后的session时间他也会详细介绍Redis Stream的设计。然后介绍了他最近做的一个“秘密项目”，把之前开发的disque以Redis Module的形式迁移到Redis，这个据作者介绍开发的工作量还是比较大的，但是为了在RedisConf18上给大家惊喜，只好push自己加班了……。然后作者讲了5.0中和cluster相关的改进，最重磅的莫过于作者要给cluster实现一个proxy，私底下交流作者觉得现在smart client在实现时都没有统一的标准，问题很多，加个proxy以统一，非smart client也可以直接使用了。然后是异步迁移的实现，这个从github上来看，会合入codis的PR实现。最后介绍的是client side caching的新feature，实际上是提供一些key的统计信息给client，client side决定是否缓存或丢弃key，这个是为了解决热点key问题的，不过一致性就要由client自己来做取舍了。关于multi io thread，作者说也是在计划中。

最后关于5.0 的发布时间，目前是还没有RC1的，按作者计划是在几周以后RC1，不过GA时间可能就比较久了，目前作者也无法确定，因为还要写很多的文档、unit test和压测，他说自己在4.0因为心急犯了错误，5.0不会再犯了。

接着Redis labs的人上台重点介绍了Redis module，使用Redis Module，能大大降低部署在AWS上应用的架构复杂性。然后RedisGraph（module）的开发者上台，介绍了他们重新实现了RedisGraph，基于新的GraphBLAS算法，插入性能和查找相邻节点性能和Neo4j相比有数量级的提升。

然后是RedisSearch（module）的开发者上台，介绍新的feature，RedisSearch是如何在cluster版本中也实现支持的，主要是使用了一个coordinator节点用来聚合结果，最后还在现场对RedisSearch的性能和AWS的对比做了一个演示，RedisSearch的作者是个柔软的胖子，昨天我们也有过私下交流，非常的风趣幽默。最后是Redis labs的人上台宣布发布Redis University，面向开发者进行Redis教学，当然也可以顺便宣传自己的产品，目前是已经上线可以注册了。

keynotes的最后邀请了stackoverflow的CEO Joel Spolsky上台来跟大家分享他的创业经历，实际是一个脱口秀的形式，Joel Spolsky非常的幽默，感觉全场一直在笑，贴个图吧，毕竟码农经常用这个网站，膜拜一下，

keynotes环节完成之后是session time，我们先听了Redis作者对Redis stream的介绍，这里主要介绍了实现Redis Stream的初衷和Redis Stream的主要接口，推荐大家看之前分享的一个ppt，对Redis Stream做了一个详细说明，和作者今天讲的思路一致，移步：Redis Stream

之后是google cloud的分享。谷歌redis云服务计划今年5-6月份上线，目前是一个beta版本，整体功能目前只有主从和单节点两种形式，内存容量从1-384GB内存，没有对源码进行深度定制化开发，直接使用VM来构建redis，同时目前不支持集群，另外有一套类似阿里云DMS的监控管理工具，不过据反馈需要收费，整体费用比例看很高。但是从现场了解到有很多客户在gcc（google cloud computing）使用redisLabs提供服务。google同学表示也是看到redis的需求之后希望自己能够在私有云提供Redis服务。同时当前也都不支持Redis Module 不支持CRDT，详细roadmap没有透露。另外会后和一个中国的google同学沟通反馈他们大部分开发同学是从aws过来的。

因为上午keynotes时间比较长，所以只有一个session时间，接着就是lunch time了，lunch是餐车的形式，人很多要排挺长队，餐食还是汉堡……这点体验不太好:)

下午先听了AWS的分享。AWS ElasticCache的负责人Audi Gutmans分享了AWS在开源项目的贡献及ElastiCahe对开源Redis的共享，Audi Gutmans首先介绍了他是PHP group的创始人，是PHP steering的委员和license持有人，另外还参与了Apache开源基金会，开源了很多项目，比如Zend Framework，Eclipse PDT，同时还是mysql的贡献者，在mysql客户端目前都还有他的代码。会议开始之前Redis作者坐到了会议的第一排，在第一排认真的进行了听讲。会议开始之后Gutmans首先介绍了aws使用和贡献的开源项目，接下去讲到了aws同学在redis的贡献。

其中最大的一个feature是SSL的支持，这个feature是由一个180几的妹子完成的，使用了aws开源的s2n的SSL库，整个库的代码比openssl简洁，同时性能提升性能比openssl好20%。会和和SSL的feature的作者交流，整体性能在加密上比没有开启降低30%，这个也和阿里云实现的版本是一致的。

会议结束之后开源看到redis作者对Gutmans还是非常尊敬，主动上去和他攀谈并握手致意。

在会议结束之后我们在展台找到aws的同学，找到了QUCHEN和他进行了短暂交流，主要确定了下aws模式下用户如果从主从变成集群是否需要更改用户客户端，这里他确定用户需要修改，我们反馈这个对用户不够友好，会影响用户业务。另外问了下aws对读写分离支持的时候有没有考虑单写入放大的或者，比如进行cpu限制或者cpu限制，他们反馈只有VM级别的流量限制，同时对于这种问题需要用户解决。在数据迁移上主要询问了如果扩容的时候大key如何迁移的问题，不过他们如果包的大小大于一定数字（256MBU左右），客户端会断开连接。咨询询问了是否使用migrate来进行迁移，QUCHEN直接说不能说了。后面来了aws的产品经理，一个女同学，我们介绍了下阿里云在Redis上进行的工作，相互交流了下就完了。

因为aws分享session时间比较短，所以在同一个房间接着Redis Labs的工程师分享了RoF（Redis on Flash）with 3D XPoint，3D XPoint是一种新型存储介质。不过这里感觉Redis Labs对技术做了很高的保密，询问性能如何，他们只回答了very fast，并没有给出详细的性能数据，然后目前Redis Labs也还是在内部测试中，没有相关产品公测。最后一页PPT是精华，和原来的on 普通SSD相比，on 3D XPoint之后，他们的架构也有很大的改变，基于3D XPoint的存储设备是直接map到虚拟地址空间中的，然后Redis Labs重新实现了引擎部分，原来是基于RocksDB的，现在是自己写的一个LMDB，用于数据的换入换出，也取消了多io线程的设计。

接下来的session和业务相关多一点，首先是“auto-scaling redis caches”，这个主要讲的是如何根据业务运行的latency和命中率，动态的调整cache的大小（基于Redis）来获取目标的latency，同时尽量降低cache的成本，主要是提到了一个cache model的概念，业务latency的下降并不是随着cache size的提高而线性下降的，可能会在某段cache size范围内，latency是完全不变的，但是过了某个点，latency会出现陡变。

我们听的最后一个session是lyft分享的关于Redis大规模使用的经验（自运维）。Lyft是一个打车软件，目前大约有2000+ instance。不过Lyft使用Redis是一个纯粹做cache的场景，遇到的问题相对简单。他们不开AOF和RDB，也没有使用Replication。最早他们使用的是twemproxy，这个自建过Redis的同学可能都知道，twemproxy是Twitter很早开源的一个Redis集群代理，现在转为闭源，开源部分也不维护了。所以Lyft就转而使用envoy，envoy目前google，apple，Netflix，腾讯等都有在用，更新也很频繁，github上看star 4000+，长期来看比较靠谱。lyft使用的路由算法是一致性hash，这个倒也符合cache场景的用法。lyft自己写了一些比较好的运维工具，redis-look，已经开源。最后因为Lyft的服务都是跑在aws上的，他们分享了一下spectre漏洞对他们的影响，大约瞬时25%+的性能，他们的做法就是把ec2规格从C4升级到C5解决问题，有钱任性~

session听完之后，会有一个meetup的时间段，供大家会后交流，有冰好的beer，这点还是不错的。我们主要和aws elasticache的工程师和产品经理做了交流。同时还遇到了redis-rdb-tools的作者，他看到我们一直在aws展台交流，就主动把我们叫过去了:)，redis-rdb-tools确实是个很不错的工具，我们在平时工单处理过程中也会推荐客户使用。开发redis-rdb-tools的哥们是一个印度人，他又做了一个专门用来优化Redis内存使用的工具，看宣传页是根据你的数据结构使用情况，来给你提供优化内存使用的建议，比如使用hash时，拆分为小hash，不要用大value等等这样的策略。我们给他推荐了阿里云的云市场，一个专门的第三方工具市场，redis-rdb-tools在github上有2000+ star，redis也在国内比较流行，从这两点来看，应该能给这位印度哥们带来不错的商机~

最后放一张图镇楼，o(*￣︶￣*)o