日前，Redis中国用户会（CRUG）首次常委会正式召开，本次会议选举出新浪微博高级DBA张冬洪为主席、阿里云数据库高级专家蔡松露为中国用户会技术大学校长。
Redis中国用户组成立于今年5月20日，是由阿里云、新浪微博、唯品会、去哪儿等Redis一线工程师联合发起的非营利性技术组织。该组织希望通过吸引Redis爱好者加入，从而推动Redis技术在中国的更多交流和应用。
包括阿里云、新浪微博、去哪儿、唯品会、明趣科技等公司参加了12月4日在北京召开的Redis中国用户会（CRUG）首次常委会。除了上述选举外，还选出常委委员长王义成（阿里云数据库产品专家）、副主席强昌金（去哪儿高级DBA）、许瑞（唯品会高级架构师 ），以及技术大学副校长李强（北京明趣科技有限公司技术合伙人）。
对于Redis在国内的使用情况，Redis中国用户会技术大学校长蔡松露在接受云栖社区采访时介绍到，Redis在国内的使用非常普遍，不仅包括BAT、微博、搜狐、小米、唯品会等，创业的互联网公司几乎也都选择Redis。
“Redis比较简单、高效、稳定、可靠，好用且易用，而且Redis在国内的生态也不错。根据网上公开的文档和方案就能够快速地bootstrap搭建起一套环境，所以Redis在国内获得了极大的繁荣。”
繁荣背后也有些问题。蔡松露称，Redis之前没有推出集群版，导致很多公司都在做同样的事情。代表性的有大名鼎鼎的开源产品Codis，也有BAT、微博、唯品会等自主研发——然而原理却类似的集群方案。有的为了解决大容量冷数据的问题，还引入了RocksDB、LevelDB等存储引擎用于底层存储，直到社区推出3.2版本，才有了官方的集群模式。
很多公司对Redis的掌控力也不同。大公司投入多，掌控力相对强一些，甚至能够修改源码，给出自己的解决方案；中型的公司使用比较熟练，能够自主搭建和维护；一些小公司也在自主搭建和维护，但是相对吃力一些，在遇到一些问题时，往往一筹莫展，网上也不一定能找到对应的文档和解决方案。
因此在Redis布道上，蔡松露打算联合国内社区的力量，把之前松散的东西整理归拢，比如常见问题和解法、行业解决方案&代码示例、原理和代码分析、优化方向&方案等，然后以系列文章、视频或直播的方式呈现给大家。“这些笨笨的脏活累活做好了，播种、锄草、施肥、浇水后，花自开。”他说，想法比较简单，但也许最奏效。
谈到未来，蔡松露认为Redis在国内会一直繁荣昌盛。尤其是随着云计算的发展——很多云计算公司也将Redis的相关产品对外输出，帮用户降低很大维护成本的同时，也会进一步促进Redis生态发展。
最后，蔡松露也解释了“主席”和“校长”、“常委会委员长”的职责：
1.主席：任职期间负责社区整体发展规划。包括不仅限于组织技术分享、社区年会、兄弟组织交流等。
2.校长：任职期间需要负责Redis技术普及和发展方向引导。包括但不限于技术分享选题审核、精尖技术交流分享等。
3.常委会委员长：组织常委会正常召开和建立社区基金会，负责社区收支等。
【附录】独家专访：中国用户会（CRUG）技术大学校长蔡松露
云栖社区：作为Redis中国用户会技术大学校长，打算从哪几个方面做好Redis在国内的布道？
蔡松露：校长职位既是一种鼓励也是一种鞭策，我本身比较擅长做技术，那我也希望能够将这个职位和我擅长的东西相结合——以技术为切入点。
当然不会去做什么天马行空高大上的东西，之前也提到了大家在使用Redis的时候遇到了一些问题，却苦于没有现成的文档和解决方案；而且有时候方案选型也比较困惑，不知该如何抉择；甚至有的用户可能就是入门小白，就想知道Redis能解决什么和如何解决他的业务问题。
所以我的想法比较简单：联合整个国内社区的力量把之前比较松散的东西整理归拢一下，比如常见问题和解法、行业解决方案&代码示例、原理和代码分析、优化方向&方案等等，然后把这些东西以文章、视频或者直播的方式呈现给大家，渠道包含但不局限于博客、微博、微信、直播平台等。
做这些的目的是希望既能解决大家的问题，也能让大家像打怪一样成长，从小白开始看进阶文章视频，有了些积累后看看原理和代码，积累比较多之后再回馈社区，形成一个比较良性的循环。
所以我觉得最开始就把这些笨笨的脏活累活做好就好了，播种锄草施肥浇水花自开，当然做这些事情是需要所有人一起参与建设，你我都是参与者之一，所以也希望大家以后多多支持。
云栖社区：就你接触到的来看，国内对Redis有哪些认知误区？并请分析下误区的产生原因？
蔡松露：最大的一个误区我觉得就是认为“Redis比较简单，不会出问题”，Redis确实设计理念&使用都比较简单，代码量也就几万行，但其实坑也比较多。
比如fork在极端条件下需要double内存、断网导致的全量同步、keys或者flushall命令导致server hang死等问题。尤其是当数据量大、访问量大、部署环境比较复杂、使用不当的时候更容易出现这些问题，而且新出的Redis Cluster方案，又新加了很多组件，也使得没有之前看上去那么简单，平时还是需要不断地投入人力来保证稳定性。
我甚至接触过一些比较大型的公司也是因为对源码没有掌控力而出过大故障，所以我觉得这里最大的一个误区就是把设计理念&使用方式简单和稳定性&可维护性混淆了。误区产生的原因也很简单，就是没有把所有的坑摸完。
云栖社区：上半年，Redis Labs宣布了一个新的Redis扩展方式：Redis Module Systemw，有人称这将有助于Redis发展为一个生态体系，你是怎么看的？
蔡松露：我觉得创始人的话已经说得够明白了，这里引用一下：
"It is not possible to cover every vertical use case with just the Redis core. Now, thanks to Redis Modules, an ecosystem of diverse solutions can flourish.
The guaranteed API and binary compatibility with future versions of Redis, allow developers to invest in and benefit from, the creation of new Redis functionality.
While Lua scripts provide a level of flexibility, Redis Modules offer increased sophistication with access to low level Redis capabilities, allowing new commands to be developed easily."
简单翻译一下就是Redis Module能够提供比lua更为low-level的数据访问和操作方式，而且Module这种抽象能够发挥大众的力量，让每个人都能按照这个标准来提供不同的计算能力，如文本搜索、图像处理、权限认证等。
我个人觉得这是一种能力的释放，能够让更多人参与进来，整个生态也会更加完善，就像Python一样，有人负责维护虚拟机，有人负责写扩展，各司其职
云栖社区：你对当下的最新版本3.2.5怎么看？对Redis未来的功能演进有什么建议或期待？
蔡松露：Redis 3.2最大的特点就是支持Redis Cluster，这是Redis一个重大的里程碑，是一件值得肯定的事情，终于结束了Redis没有集群方案的时代。
带来的问题就是Redis Cluster实现还是比较复杂的，而且对运维人员的要求也比之前要高，之前运维人员面对的是个单点问题，现在完全是分布式问题，这点可能略让大家吃不消。
Redis Cluster的另外一个问题就是生态还不算完善，Smart Client的支持也还太少，而且以前的很多坑也依然存在，如内存double、aof load过久、flushall hang机等问题。当然很多坑都在Redis 4.0中都填了，所以Redis 4.0也是一个非常值得期待的版本。
其实Redis 4.0版本的很多功能在Redis 2.X时代就有很多公司已经解了，但是很遗憾的是没有参与到社区建设之中，当然原因也有很多。如果这些功能能够提早贡献给社区，大家也就不用等待那么久了，Redis版本迭代应该也会快很多，所以希望未来还是能紧跟社区，在开源上多做贡献，也期待Redis在国内越来越好。
