关键词：算法复杂度,异步通讯,缓存策略,双数组,LRU
融云首席架构师李淼演讲
火爆的演讲现场
会议结束后参会嘉宾与李淼继续沟通
数据存储方面，在即时通讯保证消息可靠性的情况下，优先进行消息存储，通过这种方式保证消息不丢失、不乱序、不重复。对于数据存储而言，其实和I/O有点类似，对于一般的业务来讲，如果数据存储优化的好，平台优化方面就完成了60%左右的工作。
下面通过三个阶段介绍一下融云关于性能问题的定位。第一个阶段融云刚刚成立，那个时候性能问题的定位主要是通过系统监控，配合着系统日志以及诊断工具，主要监控服务器里面的CPU、内存及I/O指标。
实际上对于性能问题的定位来讲，第一个阶段是最有效的，后面的手段都是辅助研发人员对于线上问题的定位，这些都是相辅相成的：你判断问题、定位问题需要工具，工具也可以提高你判断问题、定位问题的速度。
高并发系统技术要点
对于高并发系统来讲，其实技术要点很多，我罗列了四条：异步通讯、缓存策略、数据结构及算法、数据存储。对于性能优化来讲，这四点仅仅是一部分，但如果把这四点做好，平台就能得到一个很大的提升。
首先是异步通讯，对于现在的分布式系统来讲，都需要对服务进行拆分，服务拆分以后我们需要通过一种方式将服务串联起来，现在有很多开源的解决方案或框架，但是对于RPC来讲，一般都是同步调用，有点类似于访问数据库，当前的工作线程需要等待调用端反馈结果。
如果说某个服务的响应时长十毫秒，对于调用端来讲就需要等待十毫秒，为了解决这个问题，现在很多RPC都支持异步RPC的方式，通过回调的方式解决同步RPC工作线程占用以及等待的问题。
最后一个是Actor模型，Actor模型实际上在整个软件系统上是一个属于多线程数据协调的模型。所有的请求以及返回结果会以消息的方式进行传递，融云也是使用了Actor模式作为服务间调用。
第二个是缓存策略，我们对于数据分为四层：首先是原始数据，这个数据是保存在数据库里面的;第二个是分布式缓存，对于很多无状态的服务而言，性能优化大部分依赖于分布式缓存来完成;第三个为了对数据访问进行加速，可能会使用一些本地进程内缓存，由于没有网络访问，同时直接的内存访问速度更快，所以本地缓存策略也会作为服务加速的方式;最后就是客户端缓存了，现在无论是App开发，PC客户开发都可以使用用户侧的数据存储，Web上的H5也可以使用类似localstorage解决方案，但是一旦使用了客户端存储，我们就需要设计一个健壮的数据同步模型。刨除客户端缓存的问题，为了尽可能达到使热数据离用户近一些这个目的，我们就需要想尽一切办法提高缓存的命中率。
第四数据存储，我们依然要提场景的问题。对于一般系统开发来讲，一个关系型数据库基本上就可以满足业务需求开发了，但实际上如果仅仅通过关系型数据库来做的话，即使能满足业务需求也不一定可以满足性能需求。所以说要熟知你的业务场景，根据业务场景选择合适的数据存储。除此之外，还需要了解这些存储的原理。
性能优化案例
性能优化案例内存优化篇。这个场景对于key缩短问题，对于系统当中的用户ID本身来讲长度不可控。我们通过一个哈希算法转变进制，变成64进制，这样对于超过22个字节的数据进行压缩，最终优化效果把内存的利用率降低了大概10%。
第二个内存优化主要是LRU缓存优化，如果有大量冷数据访问到系统中之后，会把热数据冲掉，这对于系统的吞吐量有很大影响。我们优化的方式是做了一个二级LRU缓存，将冷热数据按照配比进行隔离，冷数据40%，热数据60%，这样系统里热数据被淘汰的问题便得以缓解了。
性能优化案例。数据状态的延迟写入，这个场景中消息里会记录每个用户的状态。如果用户收了一千条消息，数据就要被写入一千次，我们通过另外一种模式，消息状态数据一直是在本地内存当中进行写入，待多次写入直到数据不活跃后，我们才将数据写入真实的存储里。通过这种优化，将之前的多次数据写入变成了一次数据写入。
之前监控数据每天有几千亿次需要存储和写入，通过添加缓存区，让将监控数据传输量降低了两个数量级。
数据存储。首先对于消息来讲，他的写入和读取场景是比较特殊，通过自研的存储引擎，将存储的设备降低了一半的数据量，同时保证了整个系统的响应速度。另外，调整了数据库的业务引擎，对于业务数据占用磁盘比较高的问题，优化之后的结果大概只有之前的30%左右，即存储降低了70%。
系统设计把控
另外，技术选型需要充分考虑团队对技术的接受能力，同时一定要对每个你所选东西的原理有充分认识，这样的话才能做出一个比较好的选择。