张小峰 Oray技术总监
简介
张小峰专注于高性能网络办事架构，15年C++网络应用开发和团队办理经验；在DNS架构、C++网络通信技术、各操作系统API交互、图像处理、加密算法等领域都有着深入的研究；在Oray技术团队中负责所有产品的网络办事及图像底层架构设计与开发；带领团队先后研发了多款花生壳、向日葵远程控制软件千万量级的产品，从事其中的结构设计与关键技术攻关。是Oray技术团队的领头羊与灵魂人物。
应用配景介绍作为提供各种互联网办事且具有海量用户的的Oray，我们也一直在实践各种新技术新架构；缓存方面我们从memcached、ttserver、redis等都有较多应用，其中redis我们的dns体系中有着很深度的集成使用；MySQL InnoDB memcached plugin出来挺久的了，网上还没见到国内有把它用到生产环境的实例，我今天就给大家说下小白鼠体验。
创始产品花生壳是个简单的动态域名产品，用户可以用它发布本身的各类办事，从网站到各类专用数据连接；就算在中国互联网环境如此残酷同时IPv4资源在不停萎缩的今天，这个产品还在不停的发展壮大。虽然外貌看起来是个简单的工具软件，但它为中国一代代的互联网人解决了很多基础的连接问题！
但很大一部分用户使用我们的花生壳也就是为了远程操作电脑，所以2010年，在我们埋头苦干了1年多后推出了向日葵远程控制产品，这个产品的基本功能就是让用户不需要关心IP端口等技术知识就可以远程办理控制他的所有电脑，这个产品主要依赖以下技术：
1、 通过关系型数据库办理用户主机清单；
2、 使用长连接维持被控在线状态；
3、 P2P通信技术传输控制信号以及图像信号；
4、 优化的算法尽可能的降低用户带宽占用以及提高图像质量；
5、 其他周边技术，如HTML5免插件远程控制、远程开机等。
客户端、操作系统以及相关远控技术问题我们今天先不探讨，向日葵也不是一个简单的C/S结构软件，我们需要像聊天办事器那样与客户端进行实时交互，而客户端在线量一直在凶猛的增长中，我们的系统以及运维和开发团队也就不竭的迭代并成长。
向日葵远程控制技术的数据需求上面提到，向日葵使用关系型数据库存贮某一个用户拥有哪些主机，以及这些主机的具体相关信息；在此同时，我们也需要临时存储一些关键的实时数据：
1、 主机鉴权信息
2、 主机在线状态
3、 如何连接主机
其实刚发布向日葵的几个月我们是把它们同时放在关系数据库里的，阿谁时候主要考虑的也不是办事端的性能问题，而是整个系统跑通，只是我们的数据库后来吃不用了，这一段经历不长，说真的也没啥好讲的。
缓存优化史既然存在关系数据库中分歧适，我们就开始用各种缓存技术来存储这种实时数据。
从memcached到ttservermemcached第一代的主机状态数据缓存化，我们把它放在了memcached，整个客户端的登陆过程是这样的（里头略去了各种错误处理及异常以及各种附属架构，好比负载均衡或者备份等）：
把状态等需要频繁拜候的数据放到缓存后，这个大框架到现在也还基本上是这样，API负责所有跟持久化DB的交互操作，长连接只负责跟memcached的通信，这样也制止了我们的DB有过多角色参与读写；别的这个时候我们只有一台memcached办事器，因为我们算过16G内存大约可以放上亿的主机信息。
但这些数据跑memcached真的合适吗？
在经历了两次memcached瓦解后我们也瓦解了，memcached的数据是完全放在内存里的，瓦解后所有主机全部会酿成不在线且只能通过重启所有办事器解决，而重启所有办事器意味着所有原先在线客户端都得全部重新登陆一次，这个过程会极其漫长，以小时计的。
ttserver我们要改进了，顺其自然的，我们想到了ttserver，ttserver可以在瓦解重启后恢复数据且具备主备同步功能，而丢失那部分数据我们可以在客户端登陆时从DB里自动恢复出来；
由于ttserver跟memcached通信协议上完全兼容，但为了制止全局性的灾难，我们在完成多cache办事优化后，新系统很快就上线了。
新缓存体系的结构长这样的：
完全堆叠式的设计，理论上也是可以无限扩容的，但我们没意识到ttserver几个大问题：
ttserver不支持key过期的，需要开启table database模式，并通过lua脚本的方式来实现，但该模式ttserver的运行性能相当差，而且在数据很大的时候出现不不变的现象。
