3
回复
#Full版本 pod 'Hyphenate' 完成后 项目崩溃
prf 回复了问题 • 2 人关注 • 32 次浏览 • 2017-06-27 23:03
2
回复
调用 EaseUI.getInstance().init(this, options); 初始化报错 删掉就好了。
guichun68 回复了问题 • 3 人关注 • 73 次浏览 • 2017-06-27 21:25
1
回复
iOS环信集成完，项目大了几十 ？ M，只用到了聊天含音视频功能，怎么精简啊
木云落 回复了问题 • 2 人关注 • 51 次浏览 • 2017-06-27 20:08
2
回复
刚才环信服务器是不是出问题了？好长一段时间都登录不上
fat1 回复了问题 • 3 人关注 • 55 次浏览 • 2017-06-27 19:47
1
回复
集成AndroidPDFView到项目中，报了环信的.so的错。。。。这是为什么？
geri_yang 回复了问题 • 2 人关注 • 37 次浏览 • 2017-06-27 18:30
3
回复
初始化SDK 时，程序崩溃，怎么办
geri_yang 回复了问题 • 4 人关注 • 1760 次浏览 • 2017-06-27 18:26
10
回复
pod 'Hyphenate'后和下载下来的Hyphenate 相比会缺少Hyphenate.h 文件
prf 回复了问题 • 6 人关注 • 426 次浏览 • 2017-06-27 18:04
1
最佳
环信demo里的parseManager，是否支持添加用户的其他属性（除了昵称和头像）呢？
geri_yang 回复了问题 • 2 人关注 • 26 次浏览 • 2017-06-27 18:04
1
回复
环信android扩展消息
geri_yang 回复了问题 • 2 人关注 • 32 次浏览 • 2017-06-27 18:00
0
回复
io.swagger.client.ApiException jar 包是哪个，为啥找不到呢
回复wangdong 发起了问题 • 1 人关注 • 26 次浏览 • 2017-06-27 17:19
0
评论
微信后台基于时间序的海量数据冷热分级架构设计实践
beyond 发表了文章 • 16 次浏览 • 2017-06-27 16:37
微信的后台数据存储随着微信产品特性的演进，经历了数次的架构改造，才形成如今成熟的大规模分布式存储系统，有条不紊的管理着由数千台异构机型组成的机器集群，得以支撑每天千万亿级的访问、键值以及 PB 级的数据。
作为以手机为平台的移动社交应用，微信内大部分业务生成的数据是有共性可言的：数据键值带有时间戳信息，并且单用户数据随着时间在不断的生成。我们将这类数据称为基于时间序的数据。比如朋友圈中的发表，或者移动支付的账单流水等业务生成的数据都满足这样的特征。基于时间序的数据都天然带有冷热分明属性――这是由手机的物理特性决定的，它的尺寸有限的屏幕所展示的数据只能分屏，通过手指的滑动，平滑而又连续的沿时间轴依次访问――通常是由最新生成的数据，慢慢回溯到较早前的数据。同时朋友圈等业务都是信息读扩散的应用场景，这就意味着它们生成的后台数据具有读多写少的鲜明特征。
在微信的实际应用场景中，这类数据的主要特点包括：数据量大、访问量大、重要程度高等。这些特点在现网的实际运营过程中，给我们带来了非常大的挑战，主要包括：数据量大，需求的存储容量高――基于时间序的数据通常不会删除，而是随着时间不断积累，数据量达到 PB 级别，相应需要的存储空间也与日俱增；访问量大，节日效应明显――基于时间序的数据往往是热点业务生成的数据，它们的访问量居高不下，基本维持在每分钟数十亿次的级别。尤其是在节日期间，瞬发访问量更可达平日的三至五倍；重要性高，用户感知明显，数据一旦丢失，导致用户不能正常使用产品，并因此而转化成的投诉率高。
通过堆机器来横向扩展存储自然可以应对如上的各种挑战，然而在成本预算紧张的前提下，机器数目是有限的。在这种情况下，基于时间序的海量数据的冷热分级架构便应运而生。该架构正是为了应对后台日益膨胀的这类数据，本着充分利用机器资源，发挥各种硬件介质特长的原则，结合数据的冷热分明、读多写少的访问特征而开发和设计出来的。它基于数据分层的理念，根据不同时间段的数据在访问热度和数据量上的差异，定制不同的服务策略，在纵向上扩展存储的边界。横向扩展存储是易于理解的，通过向原集群中增加相同类型的机器――其中必然涉及到一轮历史数据的迁移――最终新旧机器负载均衡，彼此之间并无差异的对外提供服务。在这种方案下，数据横向流动，系统一视同仁的对待，显然并无因地制宜思想的容身之所。而纵向扩展存储的架构便提供了这样一种思路：
对热点数据，数据量少，但承担的访问流量大，我们当然是希望它们能常驻内存，因此系统提供了有强一致保证的内存层，在应对突发流量时，也可在不涉及历史数据迁移的前提下，单独、动态的快速扩展内存层。
对历史数据，数据存量大，但承担的访问量非常有限，我们当然是不希望用昂贵的固态硬盘来存储它们，因此，系统提供了廉价的机械盘层，并且有一套透明的冷数据剥离和批量下沉的流程，将存储层中历史数据源源不断的抽离到机械盘层。
通过这样的一种纵向分层、单独扩展的思路，即为我们系统提供了极大的灵活性，解决了节日期间存储层面临的内存瓶颈，以从长远的角度为我们缓解了成本压力，解决了存储层面临的磁盘容量瓶颈。
当然一套成功的大型分布式系统仅有这些是不够的，还必须包括数据多副本复制策略以及分区算法等，也要有能应对复杂的现网运营环境的能力。我们结合各层的服务特点，制订了相对应的数据强一致算法，如内存层通过版本号控制来保证与存储层的完全一致，存储层通过 Paxos Group 实现多副本容灾，而机械盘层则通过串行写来保证。我们同时也实现了自己的去中心化的数据路由算法，确保了数据和流量的均匀分布，并且保证这种特性在横向扩展后依然成立。
通过如上工作的努力，环环相扣，我们的基于时间序的海量数据的冷热分层架构成功的应对了 PB 级数据、千亿级访问以及万亿级键值带来的挑战。
系统设计
数据模型
本文提及的海量数据的冷热分级架构是专门服务于基于时间序的数据，它们主要特征为：
a). 数据键值带有时间戳信息 ;
b). 单用户数据随着时间在不断的生成。
我们设计的架构强依赖于特性 a)，各个环节基本上是依赖于键值中的时间戳来分发数据或者进行数据排序的。至于键值中的时间戳如何生成、全局是否维持统一时间、如何维持等则不在本文的讨论范围，通常这由前端的业务特性以及后台的时间服务器策略决定的。
而特性 b) 则保证了本架构的必要性、实用性。如果数据规模有限，以用户的账户信息举例，它就像我们日常生活中的户口本，它只有一份，对单用户而言不会新增。则我们通常用固定的机器集群存储就可以，并且鲜有变更。而我们要处理的是用户的日记本、或者记账簿，它们每天都在不断生成新数据。
我们以现网某个集群的实例情况举例，说明下此类业务数据有如下的特点：
1.、数据量大，PB 级数据，万亿级键值，并且在源源不断的生成中，然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况。
2、访问量大，峰值可达每分钟数十亿次访问，尤其是在节日期间，用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100：1) 的访问特征，比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况。
3、数据安全性要求高，这类数据通常是用户感知敏感数据，一旦丢失，转化成的用户投诉率高。
存储层
数据强一致性保证
业务要求系统必须保证在数据的多份副本之间保持强一致性。――这是一个历久弥新的挑战。我们将分内存层、存储层、机械硬盘层分别来考虑数据的强一致性维持。
强一致缓存
正如前文描述，内存层作为一种强一致性分布式缓存，它完全是向存储层对齐的，自身无法判别数据有效性，本身多副本之间也没有交互的必要。它对前端而言是只读的，所有的写请求并不通过它，它只能算是存储层中数据的一个视图。所以它对前端数据有效性的承诺完全是依赖于存储层的正确性的。
Paxos Group
我们基于 Paxos Group 实现了存储层的数据一致性，通过采用无租约的方式，使得系统在保证强一致性的前提下达到了最大的可用性。Paxos 算法是由 Lesile Lamport 在论文中首提的，它唯一的作用是在多个参与者之间唯一的确定一个常量值。――这点同分布式存储没有直接关联的。我们在 Paxos 算法的基础上，设计出基于消息驱动的 Paxos Log 组件――每一条操作日志都要 Paxos 算法来确定，再进一步实现了基于 Paxos Log 的强一致性读写。
Paxos Group 因为采用了无主模型，组内所有机器在任一时刻都处于相同的地位。Paxos 算法本质是个多副本同步写算法，当且仅当系统中的多数派都接受相同值后，才会返回写成功。因此任意单一节点的失效，都不会出现系统的不可用。
强一致性写协议的主要问题来源于 Paxos 算法本身，因为要确保数据被系统内的多数派接受，需要进行多阶段的交互。我们采用如下的方法，解决了 paxos 算法写过程中出现的问题：基于 fast accept 协议优化了写算法，降低了写盘量以及协议消息发送、接收次数，最终实现了写耗时和失败的降低；基于随机避让、限制单次 Paxos 写触发 Prepare 的次数等方法，解决了 Paxos 中的活锁问题。
强一致性读协议本身和 Paxos 算法并没有太大的关系，只要确认多副本之间的多数派，即可获取到最新的数据。我们通过广播的方式获取到集群中多数机器（包含自身）的 paxos log 的状态，然后判断本机数据的有效性。
当系统中的单机节点失效，数据完全丢失的时候――这种情况是可以算是 Paxos 算法的盲区，因为该算法基于所有的参与者都不会违背自己曾经的承诺，即拜占庭失败而导致的数据不一致。――而这种情况在现网运营中可谓是常态，因此，我们引入了 Learner Only 模式。在该模式下故障机只接收已提交的数据，而不参与 Paxos 协议的写过程，意即不会因数据丢失而违背任何承诺。然后通过异步 catch up 和全量数据校验快速从其它副本中恢复数据。
为了防止多节点同时失效，我们将数据的多副本分布在不同园区的机器上。园区是同一个城市不同数据中心的概念。如此，我们的结构足以应对单数据中心完全隔离级别的灾难。
串行写入
因为对客户端透明，冷数据下沉流程作为机械硬盘层的唯一写者，则该层的数据一致性是易于实现的。我们通过三副本串行写入、全部提交才算成功的方式来实现了多副本之间的数据一致性。
作为补充，冷数据集群为数据块增加了 CRC 校验和一致性恢复队列，当单机数据不可用 (丢失或者损坏) 时，首先客户端会跳转到其它备份中读 (三机同时对外提供读服务)，一致性恢复队列会异步的从其它备份数据块中恢复本机数据。
因为采用了 No Raid 方式组织的盘组，并且同组机器间盘级别数据文件一致，在单盘故障引发数据丢失时，只要从其它机器相同序盘中传输数据文件即可。
数据分区
静态映射表
数据分区的主要目的是为了确保同层机器间的负载均衡，并且当机器规模发生变化后，在最终仍然可以达到负载均衡的一种状态。
经典的一致性哈希算法的初衷是为了健壮分布式缓存，基于运行时动态的计算哈希值和虚拟节点来进行寻址。数据存储与分布式缓存的不同在于，存储必须保证数据映射的单调性，而缓存则无此要求，所以经典的一致性哈希通常会使用机器 IP 等作为参数来进行哈希，这样造成的结果一方面是数据的落点时而发生改变，一方面是负载通常不均衡。因此我们改造了此算法。
我们通过预计算虚拟节点随机数的方法，生成了割环点同实体机器之间的映射表。该映射表最多可支持一千组的集群规模，满足在任意组数情况下，实体机器间割段长度维持差异在 2% 以内；并且增加任意组数 (总组数上限不超过一千组)，变动后的实体机器间的割段长度依然维持差异在 2% 以内。我们将此映射表硬编码，在运行时避免了计算的过程，数据根据键值哈希值寻址时，只要经过一次二分查找即可获取到对应的实体机器的编号。我们在内存层、存储层以及机械硬盘层都采用了这个映射表，保证了数据在各层路由算法的一致。在工程实现方面，我们可以合理使用这个特性来批量合并请求，以降低资源消耗，这在稍后的章节会有详细描述。
组内均衡
组是数据分区的独立单元，是虚拟节点对应的实体单位。组之间是互相独立的。每组由多台物理机器组成，这是 Paxos Group 生效的基本单位。一份数据包括的多份副本分别散落在组内的各台机器上。为了在组内机器上保证负载均衡，我们同样设计了一套算法，规定了数据副本之间的访问优先级，前端会依优先级逐一的请求数据，只要成功获取，即中断这个过程。然后我们再将副本按优先级均匀的散落在组内机器上，如此即可实现组内负载的均衡。
数据迁移
静态映射表是非常灵活的，在不达到组数上限的情况下，可以任意的增加一组或者多组机器。当然这个过程中一些数据的路由映射发生了改变，则就涉及到了历史数据的挪腾。为了在挪腾的过程中不影响服务，保证数据依然可读可写，我们开发出了对前端透明的，基于迁移标志位，通过数据双写和异步挪数据的方式实现的安全的、可回退的数据迁移流程。
最小不变块
存储层和机械硬盘层通过冷数据链接耦合在了一起。因为两层使用了相同的映射表，那么当存储层因扩容而发生迁移时，那么冷数据链接无疑也要重新寻址，进行一轮重新定位。如果我们以单键值为粒度记录冷数据链接和进行冷数据下沉，那么在万亿键值的语境下，效率无疑是低下。因此我们设计了最小不变块的算法，通过两阶段哈希，使用中间的哈希桶聚集数据，将数据键值和冷数据存储层的机器路由隔离开来。通过该算法，我们可以实现：批量的转存冷数据、热数据存储层批量的以块 (block) 为单位记录冷数据链接、当热数据存储层发生扩容时，块 (block) 内的数据不因扩容被打散掉，而可以整体的迁移到新目标机上。
工程实现
糟糕的工程实现可以毁掉一个完美的系统设计，因此，如何在工程实现的过程中，通过技术的手段，提升系统的表现，同样值得重视。
高效缓存
内存层的设计严重依赖存储层数据版本号的高效获取，那自然是版本号请求全落在内存中就可以了。因此，针对这种情况我们为定长的版本号设计了一套极简的、轻量的、行之有效的缓存――内存容量不足以支撑版本号全缓存。
它的数据结构只是一个二维数组，一维用来构建 hash 链，一维用来实现 LRU 链。每次读或者写都需要通过数组内数据的挪动，来进行更新。如此一来，我们就通过千万级数目的 LRU 链群，实现了缓存整体的 LRU 淘汰。它具有定长，可共享内存搭载，进程重启不丢失、内存使用率高等优点。
批量操作
对系统服务器而言，前端访问过来的某个请求，其对应的逻辑操作都是串行的，我们自然可以梳理这个串行流程中的 CPU 消耗点进行优化。然而当主要的瓶颈被逐渐的消灭掉后，CPU 消耗点变得分散，优化效果就变得微乎其微了。因此，我们只能寻找其它突破点。
我们发现在存储引擎、一致性协议算法的实现流程中，逻辑操作步骤多，涉及到网络交互，硬盘读写等过程。因此，我们决定合并不同请求中的相同步骤，实现批量化操作，极大的优化了 CPU 消耗。
合并的代价即是耗时略有增加，我们通过快慢分离，只针对热点数据请求中的逻辑操作进行合并，去掉了耗时中的不稳定因子，减少了耗时抖动。
请求合并
既然单机的逻辑操作性能已经得到了极大的提升，那么前后端的网络交互阶段，包括接入层的打包解包、协议处理等环节，成为了资源的主要消耗点。参考批量操作的经验，我们同样使用批量化的技术来优化性能――即将后台访问过来的单条请求 (Get) 在内存层聚合成一次批量请求 (Batch Get)。
路由收敛
因为每个数据都是根据键值单独进行路由的，如果要进行请求合并，我们就必须确保同一个批量请求内的数据，都会寻址到相同的 Paxos Group 上。因此，我们必须在内存层将落到同一台存储机器上的 Get 请求聚合起来。我们首先在内存层和存储层采用了相同的路由算法，然后将内存层的组数同存储层的组数进行对齐，来完成了这一目标。
相关工作
在设计的阶段，我们充分的调研了业界的各类方案，大到系统的整体架构，小到具体的技术点。各种方案自有应用场景、各有千秋，不能单纯以好坏区别，我们同样基于自己的业务场景，谨慎的选择合适的方案，或者弃而不用。在此尽量叙述。
处理 SNS 类业务生成的数据，业界有多种的冷热分离架构可以参考。我们以 Facebook 的 Cold Storage 系统举例而言，它也是基于冷热分层的想法，设计出了服务它们照片业务数据的存储方案。不同的是它采用了软硬件结合的方法，一方面定制专门的服务器（包括硬盘、电源等）和数据中心，一方面降低冷数据的备份数、增加纠删码等手段。
然而它们的经验我们是无法彻底套用的，主要两种原因：我们可使用的机器机型是固定的，不存在自己定制硬件的条件。同时它处理的是照片这种大 value 的数据。而我们基本上是文本这种类型的小 value 数据。从前文提及的 TB 访问量角度来看，它们处理的数据是容量瓶颈的，而我们处理的是 IO 瓶颈的，可以算是不太冷的冷数据带来的挑战。所以，我们只能实现自己的冷数据管理策略。
同样，业界有诸多关于如何实现数据一致性的方案。包括我们微信自研的 Quorum 协议，它是一种 NWR 协议，采用异步同步的方式实现数据多副本。即然是异步同步，那在多副本达到最终一致，必然存在一个时间差，那么在单机出现离线的情况下，就会有一定概率导致数据的不可用。而我们追求的是在单点故障下，所有的数据都保证强可用性。
因此，我们采用了无主的去中心化的 Paxos Group 实现了这一目标，其中非租约是 PaxosStore 架构的一个创新亮点。在故障时通常系统是抖动的，会有时断时续的状况，常见的租约做法在这种场景下容易出现反复切换主机而导致长期不可用，而 PaxosStore 的非租约结构能够轻松应对，始终提供良好的服务。PaxosStore 核心代码正在整理开源当中，预计四季度会正式发布，同时该项目的底层框架也基于我们已开源的协程库 github.com/libco。
转自“计算机与网络安全”，作者杨平安 查看全部
作为以手机为平台的移动社交应用，微信内大部分业务生成的数据是有共性可言的：数据键值带有时间戳信息，并且单用户数据随着时间在不断的生成。我们将这类数据称为基于时间序的数据。比如朋友圈中的发表，或者移动支付的账单流水等业务生成的数据都满足这样的特征。基于时间序的数据都天然带有冷热分明属性――这是由手机的物理特性决定的，它的尺寸有限的屏幕所展示的数据只能分屏，通过手指的滑动，平滑而又连续的沿时间轴依次访问――通常是由最新生成的数据，慢慢回溯到较早前的数据。同时朋友圈等业务都是信息读扩散的应用场景，这就意味着它们生成的后台数据具有读多写少的鲜明特征。
在微信的实际应用场景中，这类数据的主要特点包括：数据量大、访问量大、重要程度高等。这些特点在现网的实际运营过程中，给我们带来了非常大的挑战，主要包括：数据量大，需求的存储容量高――基于时间序的数据通常不会删除，而是随着时间不断积累，数据量达到 PB 级别，相应需要的存储空间也与日俱增；访问量大，节日效应明显――基于时间序的数据往往是热点业务生成的数据，它们的访问量居高不下，基本维持在每分钟数十亿次的级别。尤其是在节日期间，瞬发访问量更可达平日的三至五倍；重要性高，用户感知明显，数据一旦丢失，导致用户不能正常使用产品，并因此而转化成的投诉率高。
通过堆机器来横向扩展存储自然可以应对如上的各种挑战，然而在成本预算紧张的前提下，机器数目是有限的。在这种情况下，基于时间序的海量数据的冷热分级架构便应运而生。该架构正是为了应对后台日益膨胀的这类数据，本着充分利用机器资源，发挥各种硬件介质特长的原则，结合数据的冷热分明、读多写少的访问特征而开发和设计出来的。它基于数据分层的理念，根据不同时间段的数据在访问热度和数据量上的差异，定制不同的服务策略，在纵向上扩展存储的边界。横向扩展存储是易于理解的，通过向原集群中增加相同类型的机器――其中必然涉及到一轮历史数据的迁移――最终新旧机器负载均衡，彼此之间并无差异的对外提供服务。在这种方案下，数据横向流动，系统一视同仁的对待，显然并无因地制宜思想的容身之所。而纵向扩展存储的架构便提供了这样一种思路：
对热点数据，数据量少，但承担的访问流量大，我们当然是希望它们能常驻内存，因此系统提供了有强一致保证的内存层，在应对突发流量时，也可在不涉及历史数据迁移的前提下，单独、动态的快速扩展内存层。
对历史数据，数据存量大，但承担的访问量非常有限，我们当然是不希望用昂贵的固态硬盘来存储它们，因此，系统提供了廉价的机械盘层，并且有一套透明的冷数据剥离和批量下沉的流程，将存储层中历史数据源源不断的抽离到机械盘层。
通过这样的一种纵向分层、单独扩展的思路，即为我们系统提供了极大的灵活性，解决了节日期间存储层面临的内存瓶颈，以从长远的角度为我们缓解了成本压力，解决了存储层面临的磁盘容量瓶颈。
当然一套成功的大型分布式系统仅有这些是不够的，还必须包括数据多副本复制策略以及分区算法等，也要有能应对复杂的现网运营环境的能力。我们结合各层的服务特点，制订了相对应的数据强一致算法，如内存层通过版本号控制来保证与存储层的完全一致，存储层通过 Paxos Group 实现多副本容灾，而机械盘层则通过串行写来保证。我们同时也实现了自己的去中心化的数据路由算法，确保了数据和流量的均匀分布，并且保证这种特性在横向扩展后依然成立。
通过如上工作的努力，环环相扣，我们的基于时间序的海量数据的冷热分层架构成功的应对了 PB 级数据、千亿级访问以及万亿级键值带来的挑战。
系统设计
数据模型
本文提及的海量数据的冷热分级架构是专门服务于基于时间序的数据，它们主要特征为：
a). 数据键值带有时间戳信息 ;
b). 单用户数据随着时间在不断的生成。
我们设计的架构强依赖于特性 a)，各个环节基本上是依赖于键值中的时间戳来分发数据或者进行数据排序的。至于键值中的时间戳如何生成、全局是否维持统一时间、如何维持等则不在本文的讨论范围，通常这由前端的业务特性以及后台的时间服务器策略决定的。
而特性 b) 则保证了本架构的必要性、实用性。如果数据规模有限，以用户的账户信息举例，它就像我们日常生活中的户口本，它只有一份，对单用户而言不会新增。则我们通常用固定的机器集群存储就可以，并且鲜有变更。而我们要处理的是用户的日记本、或者记账簿，它们每天都在不断生成新数据。
我们以现网某个集群的实例情况举例，说明下此类业务数据有如下的特点：
1.、数据量大，PB 级数据，万亿级键值，并且在源源不断的生成中，然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况。
2、访问量大，峰值可达每分钟数十亿次访问，尤其是在节日期间，用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100：1) 的访问特征，比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况。
3、数据安全性要求高，这类数据通常是用户感知敏感数据，一旦丢失，转化成的用户投诉率高。
存储层
数据强一致性保证
业务要求系统必须保证在数据的多份副本之间保持强一致性。――这是一个历久弥新的挑战。我们将分内存层、存储层、机械硬盘层分别来考虑数据的强一致性维持。
强一致缓存
正如前文描述，内存层作为一种强一致性分布式缓存，它完全是向存储层对齐的，自身无法判别数据有效性，本身多副本之间也没有交互的必要。它对前端而言是只读的，所有的写请求并不通过它，它只能算是存储层中数据的一个视图。所以它对前端数据有效性的承诺完全是依赖于存储层的正确性的。
Paxos Group
我们基于 Paxos Group 实现了存储层的数据一致性，通过采用无租约的方式，使得系统在保证强一致性的前提下达到了最大的可用性。Paxos 算法是由 Lesile Lamport 在论文中首提的，它唯一的作用是在多个参与者之间唯一的确定一个常量值。――这点同分布式存储没有直接关联的。我们在 Paxos 算法的基础上，设计出基于消息驱动的 Paxos Log 组件――每一条操作日志都要 Paxos 算法来确定，再进一步实现了基于 Paxos Log 的强一致性读写。
Paxos Group 因为采用了无主模型，组内所有机器在任一时刻都处于相同的地位。Paxos 算法本质是个多副本同步写算法，当且仅当系统中的多数派都接受相同值后，才会返回写成功。因此任意单一节点的失效，都不会出现系统的不可用。
强一致性写协议的主要问题来源于 Paxos 算法本身，因为要确保数据被系统内的多数派接受，需要进行多阶段的交互。我们采用如下的方法，解决了 paxos 算法写过程中出现的问题：基于 fast accept 协议优化了写算法，降低了写盘量以及协议消息发送、接收次数，最终实现了写耗时和失败的降低；基于随机避让、限制单次 Paxos 写触发 Prepare 的次数等方法，解决了 Paxos 中的活锁问题。
强一致性读协议本身和 Paxos 算法并没有太大的关系，只要确认多副本之间的多数派，即可获取到最新的数据。我们通过广播的方式获取到集群中多数机器（包含自身）的 paxos log 的状态，然后判断本机数据的有效性。
当系统中的单机节点失效，数据完全丢失的时候――这种情况是可以算是 Paxos 算法的盲区，因为该算法基于所有的参与者都不会违背自己曾经的承诺，即拜占庭失败而导致的数据不一致。――而这种情况在现网运营中可谓是常态，因此，我们引入了 Learner Only 模式。在该模式下故障机只接收已提交的数据，而不参与 Paxos 协议的写过程，意即不会因数据丢失而违背任何承诺。然后通过异步 catch up 和全量数据校验快速从其它副本中恢复数据。
为了防止多节点同时失效，我们将数据的多副本分布在不同园区的机器上。园区是同一个城市不同数据中心的概念。如此，我们的结构足以应对单数据中心完全隔离级别的灾难。
串行写入
因为对客户端透明，冷数据下沉流程作为机械硬盘层的唯一写者，则该层的数据一致性是易于实现的。我们通过三副本串行写入、全部提交才算成功的方式来实现了多副本之间的数据一致性。
作为补充，冷数据集群为数据块增加了 CRC 校验和一致性恢复队列，当单机数据不可用 (丢失或者损坏) 时，首先客户端会跳转到其它备份中读 (三机同时对外提供读服务)，一致性恢复队列会异步的从其它备份数据块中恢复本机数据。
因为采用了 No Raid 方式组织的盘组，并且同组机器间盘级别数据文件一致，在单盘故障引发数据丢失时，只要从其它机器相同序盘中传输数据文件即可。
数据分区
静态映射表
数据分区的主要目的是为了确保同层机器间的负载均衡，并且当机器规模发生变化后，在最终仍然可以达到负载均衡的一种状态。
经典的一致性哈希算法的初衷是为了健壮分布式缓存，基于运行时动态的计算哈希值和虚拟节点来进行寻址。数据存储与分布式缓存的不同在于，存储必须保证数据映射的单调性，而缓存则无此要求，所以经典的一致性哈希通常会使用机器 IP 等作为参数来进行哈希，这样造成的结果一方面是数据的落点时而发生改变，一方面是负载通常不均衡。因此我们改造了此算法。
我们通过预计算虚拟节点随机数的方法，生成了割环点同实体机器之间的映射表。该映射表最多可支持一千组的集群规模，满足在任意组数情况下，实体机器间割段长度维持差异在 2% 以内；并且增加任意组数 (总组数上限不超过一千组)，变动后的实体机器间的割段长度依然维持差异在 2% 以内。我们将此映射表硬编码，在运行时避免了计算的过程，数据根据键值哈希值寻址时，只要经过一次二分查找即可获取到对应的实体机器的编号。我们在内存层、存储层以及机械硬盘层都采用了这个映射表，保证了数据在各层路由算法的一致。在工程实现方面，我们可以合理使用这个特性来批量合并请求，以降低资源消耗，这在稍后的章节会有详细描述。
组内均衡
组是数据分区的独立单元，是虚拟节点对应的实体单位。组之间是互相独立的。每组由多台物理机器组成，这是 Paxos Group 生效的基本单位。一份数据包括的多份副本分别散落在组内的各台机器上。为了在组内机器上保证负载均衡，我们同样设计了一套算法，规定了数据副本之间的访问优先级，前端会依优先级逐一的请求数据，只要成功获取，即中断这个过程。然后我们再将副本按优先级均匀的散落在组内机器上，如此即可实现组内负载的均衡。
数据迁移
静态映射表是非常灵活的，在不达到组数上限的情况下，可以任意的增加一组或者多组机器。当然这个过程中一些数据的路由映射发生了改变，则就涉及到了历史数据的挪腾。为了在挪腾的过程中不影响服务，保证数据依然可读可写，我们开发出了对前端透明的，基于迁移标志位，通过数据双写和异步挪数据的方式实现的安全的、可回退的数据迁移流程。
最小不变块
存储层和机械硬盘层通过冷数据链接耦合在了一起。因为两层使用了相同的映射表，那么当存储层因扩容而发生迁移时，那么冷数据链接无疑也要重新寻址，进行一轮重新定位。如果我们以单键值为粒度记录冷数据链接和进行冷数据下沉，那么在万亿键值的语境下，效率无疑是低下。因此我们设计了最小不变块的算法，通过两阶段哈希，使用中间的哈希桶聚集数据，将数据键值和冷数据存储层的机器路由隔离开来。通过该算法，我们可以实现：批量的转存冷数据、热数据存储层批量的以块 (block) 为单位记录冷数据链接、当热数据存储层发生扩容时，块 (block) 内的数据不因扩容被打散掉，而可以整体的迁移到新目标机上。
工程实现
糟糕的工程实现可以毁掉一个完美的系统设计，因此，如何在工程实现的过程中，通过技术的手段，提升系统的表现，同样值得重视。
高效缓存
内存层的设计严重依赖存储层数据版本号的高效获取，那自然是版本号请求全落在内存中就可以了。因此，针对这种情况我们为定长的版本号设计了一套极简的、轻量的、行之有效的缓存――内存容量不足以支撑版本号全缓存。
它的数据结构只是一个二维数组，一维用来构建 hash 链，一维用来实现 LRU 链。每次读或者写都需要通过数组内数据的挪动，来进行更新。如此一来，我们就通过千万级数目的 LRU 链群，实现了缓存整体的 LRU 淘汰。它具有定长，可共享内存搭载，进程重启不丢失、内存使用率高等优点。
批量操作
对系统服务器而言，前端访问过来的某个请求，其对应的逻辑操作都是串行的，我们自然可以梳理这个串行流程中的 CPU 消耗点进行优化。然而当主要的瓶颈被逐渐的消灭掉后，CPU 消耗点变得分散，优化效果就变得微乎其微了。因此，我们只能寻找其它突破点。
我们发现在存储引擎、一致性协议算法的实现流程中，逻辑操作步骤多，涉及到网络交互，硬盘读写等过程。因此，我们决定合并不同请求中的相同步骤，实现批量化操作，极大的优化了 CPU 消耗。
合并的代价即是耗时略有增加，我们通过快慢分离，只针对热点数据请求中的逻辑操作进行合并，去掉了耗时中的不稳定因子，减少了耗时抖动。
请求合并
既然单机的逻辑操作性能已经得到了极大的提升，那么前后端的网络交互阶段，包括接入层的打包解包、协议处理等环节，成为了资源的主要消耗点。参考批量操作的经验，我们同样使用批量化的技术来优化性能――即将后台访问过来的单条请求 (Get) 在内存层聚合成一次批量请求 (Batch Get)。
路由收敛
因为每个数据都是根据键值单独进行路由的，如果要进行请求合并，我们就必须确保同一个批量请求内的数据，都会寻址到相同的 Paxos Group 上。因此，我们必须在内存层将落到同一台存储机器上的 Get 请求聚合起来。我们首先在内存层和存储层采用了相同的路由算法，然后将内存层的组数同存储层的组数进行对齐，来完成了这一目标。
相关工作
在设计的阶段，我们充分的调研了业界的各类方案，大到系统的整体架构，小到具体的技术点。各种方案自有应用场景、各有千秋，不能单纯以好坏区别，我们同样基于自己的业务场景，谨慎的选择合适的方案，或者弃而不用。在此尽量叙述。
处理 SNS 类业务生成的数据，业界有多种的冷热分离架构可以参考。我们以 Facebook 的 Cold Storage 系统举例而言，它也是基于冷热分层的想法，设计出了服务它们照片业务数据的存储方案。不同的是它采用了软硬件结合的方法，一方面定制专门的服务器（包括硬盘、电源等）和数据中心，一方面降低冷数据的备份数、增加纠删码等手段。
然而它们的经验我们是无法彻底套用的，主要两种原因：我们可使用的机器机型是固定的，不存在自己定制硬件的条件。同时它处理的是照片这种大 value 的数据。而我们基本上是文本这种类型的小 value 数据。从前文提及的 TB 访问量角度来看，它们处理的数据是容量瓶颈的，而我们处理的是 IO 瓶颈的，可以算是不太冷的冷数据带来的挑战。所以，我们只能实现自己的冷数据管理策略。
同样，业界有诸多关于如何实现数据一致性的方案。包括我们微信自研的 Quorum 协议，它是一种 NWR 协议，采用异步同步的方式实现数据多副本。即然是异步同步，那在多副本达到最终一致，必然存在一个时间差，那么在单机出现离线的情况下，就会有一定概率导致数据的不可用。而我们追求的是在单点故障下，所有的数据都保证强可用性。
因此，我们采用了无主的去中心化的 Paxos Group 实现了这一目标，其中非租约是 PaxosStore 架构的一个创新亮点。在故障时通常系统是抖动的，会有时断时续的状况，常见的租约做法在这种场景下容易出现反复切换主机而导致长期不可用，而 PaxosStore 的非租约结构能够轻松应对，始终提供良好的服务。PaxosStore 核心代码正在整理开源当中，预计四季度会正式发布，同时该项目的底层框架也基于我们已开源的协程库 github.com/libco。
转自“计算机与网络安全”，作者杨平安 查看全部
微信的后台数据存储随着微信产品特性的演进，经历了数次的架构改造，才形成如今成熟的大规模分布式存储系统，有条不紊的管理着由数千台异构机型组成的机器集群，得以支撑每天千万亿级的访问、键值以及 PB 级的数据。
作为以手机为平台的移动社交应用，微信内大部分业务生成的数据是有共性可言的：数据键值带有时间戳信息，并且单用户数据随着时间在不断的生成。我们将这类数据称为基于时间序的数据。比如朋友圈中的发表，或者移动支付的账单流水等业务生成的数据都满足这样的特征。基于时间序的数据都天然带有冷热分明属性――这是由手机的物理特性决定的，它的尺寸有限的屏幕所展示的数据只能分屏，通过手指的滑动，平滑而又连续的沿时间轴依次访问――通常是由最新生成的数据，慢慢回溯到较早前的数据。同时朋友圈等业务都是信息读扩散的应用场景，这就意味着它们生成的后台数据具有读多写少的鲜明特征。
通过堆机器来横向扩展存储自然可以应对如上的各种挑战，然而在成本预算紧张的前提下，机器数目是有限的。在这种情况下，基于时间序的海量数据的冷热分级架构便应运而生。该架构正是为了应对后台日益膨胀的这类数据，本着充分利用机器资源，发挥各种硬件介质特长的原则，结合数据的冷热分明、读多写少的访问特征而开发和设计出来的。它基于数据分层的理念，根据不同时间段的数据在访问热度和数据量上的差异，定制不同的服务策略，在纵向上扩展存储的边界。横向扩展存储是易于理解的，通过向原集群中增加相同类型的机器――其中必然涉及到一轮历史数据的迁移――最终新旧机器负载均衡，彼此之间并无差异的对外提供服务。在这种方案下，数据横向流动，系统一视同仁的对待，显然并无因地制宜思想的容身之所。而纵向扩展存储的架构便提供了这样一种思路：
对热点数据，数据量少，但承担的访问流量大，我们当然是希望它们能常驻内存，因此系统提供了有强一致保证的内存层，在应对突发流量时，也可在不涉及历史数据迁移的前提下，单独、动态的快速扩展内存层。
对历史数据，数据存量大，但承担的访问量非常有限，我们当然是不希望用昂贵的固态硬盘来存储它们，因此，系统提供了廉价的机械盘层，并且有一套透明的冷数据剥离和批量下沉的流程，将存储层中历史数据源源不断的抽离到机械盘层。
通过这样的一种纵向分层、单独扩展的思路，即为我们系统提供了极大的灵活性，解决了节日期间存储层面临的内存瓶颈，以从长远的角度为我们缓解了成本压力，解决了存储层面临的磁盘容量瓶颈。
当然一套成功的大型分布式系统仅有这些是不够的，还必须包括数据多副本复制策略以及分区算法等，也要有能应对复杂的现网运营环境的能力。我们结合各层的服务特点，制订了相对应的数据强一致算法，如内存层通过版本号控制来保证与存储层的完全一致，存储层通过 Paxos Group 实现多副本容灾，而机械盘层则通过串行写来保证。我们同时也实现了自己的去中心化的数据路由算法，确保了数据和流量的均匀分布，并且保证这种特性在横向扩展后依然成立。
通过如上工作的努力，环环相扣，我们的基于时间序的海量数据的冷热分层架构成功的应对了 PB 级数据、千亿级访问以及万亿级键值带来的挑战。
系统设计
数据模型
本文提及的海量数据的冷热分级架构是专门服务于基于时间序的数据，它们主要特征为：
a). 数据键值带有时间戳信息 ;
b). 单用户数据随着时间在不断的生成。
我们设计的架构强依赖于特性 a)，各个环节基本上是依赖于键值中的时间戳来分发数据或者进行数据排序的。至于键值中的时间戳如何生成、全局是否维持统一时间、如何维持等则不在本文的讨论范围，通常这由前端的业务特性以及后台的时间服务器策略决定的。
而特性 b) 则保证了本架构的必要性、实用性。如果数据规模有限，以用户的账户信息举例，它就像我们日常生活中的户口本，它只有一份，对单用户而言不会新增。则我们通常用固定的机器集群存储就可以，并且鲜有变更。而我们要处理的是用户的日记本、或者记账簿，它们每天都在不断生成新数据。
我们以现网某个集群的实例情况举例，说明下此类业务数据有如下的特点：
1.、数据量大，PB 级数据，万亿级键值，并且在源源不断的生成中，然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况。
2、访问量大，峰值可达每分钟数十亿次访问，尤其是在节日期间，用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100：1) 的访问特征，比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况。
3、数据安全性要求高，这类数据通常是用户感知敏感数据，一旦丢失，转化成的用户投诉率高。
存储层
数据强一致性保证
业务要求系统必须保证在数据的多份副本之间保持强一致性。――这是一个历久弥新的挑战。我们将分内存层、存储层、机械硬盘层分别来考虑数据的强一致性维持。
强一致缓存
正如前文描述，内存层作为一种强一致性分布式缓存，它完全是向存储层对齐的，自身无法判别数据有效性，本身多副本之间也没有交互的必要。它对前端而言是只读的，所有的写请求并不通过它，它只能算是存储层中数据的一个视图。所以它对前端数据有效性的承诺完全是依赖于存储层的正确性的。
Paxos Group
我们基于 Paxos Group 实现了存储层的数据一致性，通过采用无租约的方式，使得系统在保证强一致性的前提下达到了最大的可用性。Paxos 算法是由 Lesile Lamport 在论文中首提的，它唯一的作用是在多个参与者之间唯一的确定一个常量值。――这点同分布式存储没有直接关联的。我们在 Paxos 算法的基础上，设计出基于消息驱动的 Paxos Log 组件――每一条操作日志都要 Paxos 算法来确定，再进一步实现了基于 Paxos Log 的强一致性读写。
Paxos Group 因为采用了无主模型，组内所有机器在任一时刻都处于相同的地位。Paxos 算法本质是个多副本同步写算法，当且仅当系统中的多数派都接受相同值后，才会返回写成功。因此任意单一节点的失效，都不会出现系统的不可用。
强一致性写协议的主要问题来源于 Paxos 算法本身，因为要确保数据被系统内的多数派接受，需要进行多阶段的交互。我们采用如下的方法，解决了 paxos 算法写过程中出现的问题：基于 fast accept 协议优化了写算法，降低了写盘量以及协议消息发送、接收次数，最终实现了写耗时和失败的降低；基于随机避让、限制单次 Paxos 写触发 Prepare 的次数等方法，解决了 Paxos 中的活锁问题。
强一致性读协议本身和 Paxos 算法并没有太大的关系，只要确认多副本之间的多数派，即可获取到最新的数据。我们通过广播的方式获取到集群中多数机器（包含自身）的 paxos log 的状态，然后判断本机数据的有效性。
当系统中的单机节点失效，数据完全丢失的时候――这种情况是可以算是 Paxos 算法的盲区，因为该算法基于所有的参与者都不会违背自己曾经的承诺，即拜占庭失败而导致的数据不一致。――而这种情况在现网运营中可谓是常态，因此，我们引入了 Learner Only 模式。在该模式下故障机只接收已提交的数据，而不参与 Paxos 协议的写过程，意即不会因数据丢失而违背任何承诺。然后通过异步 catch up 和全量数据校验快速从其它副本中恢复数据。
为了防止多节点同时失效，我们将数据的多副本分布在不同园区的机器上。园区是同一个城市不同数据中心的概念。如此，我们的结构足以应对单数据中心完全隔离级别的灾难。
串行写入
因为对客户端透明，冷数据下沉流程作为机械硬盘层的唯一写者，则该层的数据一致性是易于实现的。我们通过三副本串行写入、全部提交才算成功的方式来实现了多副本之间的数据一致性。
作为补充，冷数据集群为数据块增加了 CRC 校验和一致性恢复队列，当单机数据不可用 (丢失或者损坏) 时，首先客户端会跳转到其它备份中读 (三机同时对外提供读服务)，一致性恢复队列会异步的从其它备份数据块中恢复本机数据。
因为采用了 No Raid 方式组织的盘组，并且同组机器间盘级别数据文件一致，在单盘故障引发数据丢失时，只要从其它机器相同序盘中传输数据文件即可。
数据分区
静态映射表
数据分区的主要目的是为了确保同层机器间的负载均衡，并且当机器规模发生变化后，在最终仍然可以达到负载均衡的一种状态。
经典的一致性哈希算法的初衷是为了健壮分布式缓存，基于运行时动态的计算哈希值和虚拟节点来进行寻址。数据存储与分布式缓存的不同在于，存储必须保证数据映射的单调性，而缓存则无此要求，所以经典的一致性哈希通常会使用机器 IP 等作为参数来进行哈希，这样造成的结果一方面是数据的落点时而发生改变，一方面是负载通常不均衡。因此我们改造了此算法。
我们通过预计算虚拟节点随机数的方法，生成了割环点同实体机器之间的映射表。该映射表最多可支持一千组的集群规模，满足在任意组数情况下，实体机器间割段长度维持差异在 2% 以内；并且增加任意组数 (总组数上限不超过一千组)，变动后的实体机器间的割段长度依然维持差异在 2% 以内。我们将此映射表硬编码，在运行时避免了计算的过程，数据根据键值哈希值寻址时，只要经过一次二分查找即可获取到对应的实体机器的编号。我们在内存层、存储层以及机械硬盘层都采用了这个映射表，保证了数据在各层路由算法的一致。在工程实现方面，我们可以合理使用这个特性来批量合并请求，以降低资源消耗，这在稍后的章节会有详细描述。
组内均衡
组是数据分区的独立单元，是虚拟节点对应的实体单位。组之间是互相独立的。每组由多台物理机器组成，这是 Paxos Group 生效的基本单位。一份数据包括的多份副本分别散落在组内的各台机器上。为了在组内机器上保证负载均衡，我们同样设计了一套算法，规定了数据副本之间的访问优先级，前端会依优先级逐一的请求数据，只要成功获取，即中断这个过程。然后我们再将副本按优先级均匀的散落在组内机器上，如此即可实现组内负载的均衡。
数据迁移
静态映射表是非常灵活的，在不达到组数上限的情况下，可以任意的增加一组或者多组机器。当然这个过程中一些数据的路由映射发生了改变，则就涉及到了历史数据的挪腾。为了在挪腾的过程中不影响服务，保证数据依然可读可写，我们开发出了对前端透明的，基于迁移标志位，通过数据双写和异步挪数据的方式实现的安全的、可回退的数据迁移流程。
最小不变块
存储层和机械硬盘层通过冷数据链接耦合在了一起。因为两层使用了相同的映射表，那么当存储层因扩容而发生迁移时，那么冷数据链接无疑也要重新寻址，进行一轮重新定位。如果我们以单键值为粒度记录冷数据链接和进行冷数据下沉，那么在万亿键值的语境下，效率无疑是低下。因此我们设计了最小不变块的算法，通过两阶段哈希，使用中间的哈希桶聚集数据，将数据键值和冷数据存储层的机器路由隔离开来。通过该算法，我们可以实现：批量的转存冷数据、热数据存储层批量的以块 (block) 为单位记录冷数据链接、当热数据存储层发生扩容时，块 (block) 内的数据不因扩容被打散掉，而可以整体的迁移到新目标机上。
工程实现
糟糕的工程实现可以毁掉一个完美的系统设计，因此，如何在工程实现的过程中，通过技术的手段，提升系统的表现，同样值得重视。
高效缓存
内存层的设计严重依赖存储层数据版本号的高效获取，那自然是版本号请求全落在内存中就可以了。因此，针对这种情况我们为定长的版本号设计了一套极简的、轻量的、行之有效的缓存――内存容量不足以支撑版本号全缓存。
它的数据结构只是一个二维数组，一维用来构建 hash 链，一维用来实现 LRU 链。每次读或者写都需要通过数组内数据的挪动，来进行更新。如此一来，我们就通过千万级数目的 LRU 链群，实现了缓存整体的 LRU 淘汰。它具有定长，可共享内存搭载，进程重启不丢失、内存使用率高等优点。
批量操作
对系统服务器而言，前端访问过来的某个请求，其对应的逻辑操作都是串行的，我们自然可以梳理这个串行流程中的 CPU 消耗点进行优化。然而当主要的瓶颈被逐渐的消灭掉后，CPU 消耗点变得分散，优化效果就变得微乎其微了。因此，我们只能寻找其它突破点。
我们发现在存储引擎、一致性协议算法的实现流程中，逻辑操作步骤多，涉及到网络交互，硬盘读写等过程。因此，我们决定合并不同请求中的相同步骤，实现批量化操作，极大的优化了 CPU 消耗。
合并的代价即是耗时略有增加，我们通过快慢分离，只针对热点数据请求中的逻辑操作进行合并，去掉了耗时中的不稳定因子，减少了耗时抖动。
请求合并
既然单机的逻辑操作性能已经得到了极大的提升，那么前后端的网络交互阶段，包括接入层的打包解包、协议处理等环节，成为了资源的主要消耗点。参考批量操作的经验，我们同样使用批量化的技术来优化性能――即将后台访问过来的单条请求 (Get) 在内存层聚合成一次批量请求 (Batch Get)。
路由收敛
因为每个数据都是根据键值单独进行路由的，如果要进行请求合并，我们就必须确保同一个批量请求内的数据，都会寻址到相同的 Paxos Group 上。因此，我们必须在内存层将落到同一台存储机器上的 Get 请求聚合起来。我们首先在内存层和存储层采用了相同的路由算法，然后将内存层的组数同存储层的组数进行对齐，来完成了这一目标。
相关工作
在设计的阶段，我们充分的调研了业界的各类方案，大到系统的整体架构，小到具体的技术点。各种方案自有应用场景、各有千秋，不能单纯以好坏区别，我们同样基于自己的业务场景，谨慎的选择合适的方案，或者弃而不用。在此尽量叙述。
处理 SNS 类业务生成的数据，业界有多种的冷热分离架构可以参考。我们以 Facebook 的 Cold Storage 系统举例而言，它也是基于冷热分层的想法，设计出了服务它们照片业务数据的存储方案。不同的是它采用了软硬件结合的方法，一方面定制专门的服务器（包括硬盘、电源等）和数据中心，一方面降低冷数据的备份数、增加纠删码等手段。
然而它们的经验我们是无法彻底套用的，主要两种原因：我们可使用的机器机型是固定的，不存在自己定制硬件的条件。同时它处理的是照片这种大 value 的数据。而我们基本上是文本这种类型的小 value 数据。从前文提及的 TB 访问量角度来看，它们处理的数据是容量瓶颈的，而我们处理的是 IO 瓶颈的，可以算是不太冷的冷数据带来的挑战。所以，我们只能实现自己的冷数据管理策略。
同样，业界有诸多关于如何实现数据一致性的方案。包括我们微信自研的 Quorum 协议，它是一种 NWR 协议，采用异步同步的方式实现数据多副本。即然是异步同步，那在多副本达到最终一致，必然存在一个时间差，那么在单机出现离线的情况下，就会有一定概率导致数据的不可用。而我们追求的是在单点故障下，所有的数据都保证强可用性。
因此，我们采用了无主的去中心化的 Paxos Group 实现了这一目标，其中非租约是 PaxosStore 架构的一个创新亮点。在故障时通常系统是抖动的，会有时断时续的状况，常见的租约做法在这种场景下容易出现反复切换主机而导致长期不可用，而 PaxosStore 的非租约结构能够轻松应对，始终提供良好的服务。PaxosStore 核心代码正在整理开源当中，预计四季度会正式发布，同时该项目的底层框架也基于我们已开源的协程库 github.com/libco。
转自“计算机与网络安全”，作者杨平安
作为以手机为平台的移动社交应用，微信内大部分业务生成的数据是有共性可言的：数据键值带有时间戳信息，并且单用户数据随着时间在不断的生成。我们将这类数据称为基于时间序的数据。比如朋友圈中的发表，或者移动支付的账单流水等业务生成的数据都满足这样的特征。基于时间序的数据都天然带有冷热分明属性――这是由手机的物理特性决定的，它的尺寸有限的屏幕所展示的数据只能分屏，通过手指的滑动，平滑而又连续的沿时间轴依次访问――通常是由最新生成的数据，慢慢回溯到较早前的数据。同时朋友圈等业务都是信息读扩散的应用场景，这就意味着它们生成的后台数据具有读多写少的鲜明特征。
- 在微信的实际应用场景中，这类数据的主要特点包括：数据量大、访问量大、重要程度高等。这些特点在现网的实际运营过程中，给我们带来了非常大的挑战，主要包括：
- 数据量大，需求的存储容量高――基于时间序的数据通常不会删除，而是随着时间不断积累，数据量达到 PB 级别，相应需要的存储空间也与日俱增；
- 访问量大，节日效应明显――基于时间序的数据往往是热点业务生成的数据，它们的访问量居高不下，基本维持在每分钟数十亿次的级别。尤其是在节日期间，瞬发访问量更可达平日的三至五倍；
- 重要性高，用户感知明显，数据一旦丢失，导致用户不能正常使用产品，并因此而转化成的投诉率高。
通过堆机器来横向扩展存储自然可以应对如上的各种挑战，然而在成本预算紧张的前提下，机器数目是有限的。在这种情况下，基于时间序的海量数据的冷热分级架构便应运而生。该架构正是为了应对后台日益膨胀的这类数据，本着充分利用机器资源，发挥各种硬件介质特长的原则，结合数据的冷热分明、读多写少的访问特征而开发和设计出来的。它基于数据分层的理念，根据不同时间段的数据在访问热度和数据量上的差异，定制不同的服务策略，在纵向上扩展存储的边界。横向扩展存储是易于理解的，通过向原集群中增加相同类型的机器――其中必然涉及到一轮历史数据的迁移――最终新旧机器负载均衡，彼此之间并无差异的对外提供服务。在这种方案下，数据横向流动，系统一视同仁的对待，显然并无因地制宜思想的容身之所。而纵向扩展存储的架构便提供了这样一种思路：
对热点数据，数据量少，但承担的访问流量大，我们当然是希望它们能常驻内存，因此系统提供了有强一致保证的内存层，在应对突发流量时，也可在不涉及历史数据迁移的前提下，单独、动态的快速扩展内存层。
对历史数据，数据存量大，但承担的访问量非常有限，我们当然是不希望用昂贵的固态硬盘来存储它们，因此，系统提供了廉价的机械盘层，并且有一套透明的冷数据剥离和批量下沉的流程，将存储层中历史数据源源不断的抽离到机械盘层。
通过这样的一种纵向分层、单独扩展的思路，即为我们系统提供了极大的灵活性，解决了节日期间存储层面临的内存瓶颈，以从长远的角度为我们缓解了成本压力，解决了存储层面临的磁盘容量瓶颈。
当然一套成功的大型分布式系统仅有这些是不够的，还必须包括数据多副本复制策略以及分区算法等，也要有能应对复杂的现网运营环境的能力。我们结合各层的服务特点，制订了相对应的数据强一致算法，如内存层通过版本号控制来保证与存储层的完全一致，存储层通过 Paxos Group 实现多副本容灾，而机械盘层则通过串行写来保证。我们同时也实现了自己的去中心化的数据路由算法，确保了数据和流量的均匀分布，并且保证这种特性在横向扩展后依然成立。
通过如上工作的努力，环环相扣，我们的基于时间序的海量数据的冷热分层架构成功的应对了 PB 级数据、千亿级访问以及万亿级键值带来的挑战。
系统设计
数据模型
本文提及的海量数据的冷热分级架构是专门服务于基于时间序的数据，它们主要特征为：
a). 数据键值带有时间戳信息 ;
b). 单用户数据随着时间在不断的生成。
我们设计的架构强依赖于特性 a)，各个环节基本上是依赖于键值中的时间戳来分发数据或者进行数据排序的。至于键值中的时间戳如何生成、全局是否维持统一时间、如何维持等则不在本文的讨论范围，通常这由前端的业务特性以及后台的时间服务器策略决定的。
而特性 b) 则保证了本架构的必要性、实用性。如果数据规模有限，以用户的账户信息举例，它就像我们日常生活中的户口本，它只有一份，对单用户而言不会新增。则我们通常用固定的机器集群存储就可以，并且鲜有变更。而我们要处理的是用户的日记本、或者记账簿，它们每天都在不断生成新数据。
我们以现网某个集群的实例情况举例，说明下此类业务数据有如下的特点：
1.、数据量大，PB 级数据，万亿级键值，并且在源源不断的生成中，然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况。
2、访问量大，峰值可达每分钟数十亿次访问，尤其是在节日期间，用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100：1) 的访问特征，比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况。
3、数据安全性要求高，这类数据通常是用户感知敏感数据，一旦丢失，转化成的用户投诉率高。
存储层
数据强一致性保证
业务要求系统必须保证在数据的多份副本之间保持强一致性。――这是一个历久弥新的挑战。我们将分内存层、存储层、机械硬盘层分别来考虑数据的强一致性维持。
强一致缓存
正如前文描述，内存层作为一种强一致性分布式缓存，它完全是向存储层对齐的，自身无法判别数据有效性，本身多副本之间也没有交互的必要。它对前端而言是只读的，所有的写请求并不通过它，它只能算是存储层中数据的一个视图。所以它对前端数据有效性的承诺完全是依赖于存储层的正确性的。
Paxos Group
我们基于 Paxos Group 实现了存储层的数据一致性，通过采用无租约的方式，使得系统在保证强一致性的前提下达到了最大的可用性。Paxos 算法是由 Lesile Lamport 在论文中首提的，它唯一的作用是在多个参与者之间唯一的确定一个常量值。――这点同分布式存储没有直接关联的。我们在 Paxos 算法的基础上，设计出基于消息驱动的 Paxos Log 组件――每一条操作日志都要 Paxos 算法来确定，再进一步实现了基于 Paxos Log 的强一致性读写。
Paxos Group 因为采用了无主模型，组内所有机器在任一时刻都处于相同的地位。Paxos 算法本质是个多副本同步写算法，当且仅当系统中的多数派都接受相同值后，才会返回写成功。因此任意单一节点的失效，都不会出现系统的不可用。
强一致性写协议的主要问题来源于 Paxos 算法本身，因为要确保数据被系统内的多数派接受，需要进行多阶段的交互。我们采用如下的方法，解决了 paxos 算法写过程中出现的问题：基于 fast accept 协议优化了写算法，降低了写盘量以及协议消息发送、接收次数，最终实现了写耗时和失败的降低；基于随机避让、限制单次 Paxos 写触发 Prepare 的次数等方法，解决了 Paxos 中的活锁问题。
强一致性读协议本身和 Paxos 算法并没有太大的关系，只要确认多副本之间的多数派，即可获取到最新的数据。我们通过广播的方式获取到集群中多数机器（包含自身）的 paxos log 的状态，然后判断本机数据的有效性。
当系统中的单机节点失效，数据完全丢失的时候――这种情况是可以算是 Paxos 算法的盲区，因为该算法基于所有的参与者都不会违背自己曾经的承诺，即拜占庭失败而导致的数据不一致。――而这种情况在现网运营中可谓是常态，因此，我们引入了 Learner Only 模式。在该模式下故障机只接收已提交的数据，而不参与 Paxos 协议的写过程，意即不会因数据丢失而违背任何承诺。然后通过异步 catch up 和全量数据校验快速从其它副本中恢复数据。
为了防止多节点同时失效，我们将数据的多副本分布在不同园区的机器上。园区是同一个城市不同数据中心的概念。如此，我们的结构足以应对单数据中心完全隔离级别的灾难。
串行写入
因为对客户端透明，冷数据下沉流程作为机械硬盘层的唯一写者，则该层的数据一致性是易于实现的。我们通过三副本串行写入、全部提交才算成功的方式来实现了多副本之间的数据一致性。
作为补充，冷数据集群为数据块增加了 CRC 校验和一致性恢复队列，当单机数据不可用 (丢失或者损坏) 时，首先客户端会跳转到其它备份中读 (三机同时对外提供读服务)，一致性恢复队列会异步的从其它备份数据块中恢复本机数据。
因为采用了 No Raid 方式组织的盘组，并且同组机器间盘级别数据文件一致，在单盘故障引发数据丢失时，只要从其它机器相同序盘中传输数据文件即可。
数据分区
静态映射表
数据分区的主要目的是为了确保同层机器间的负载均衡，并且当机器规模发生变化后，在最终仍然可以达到负载均衡的一种状态。
经典的一致性哈希算法的初衷是为了健壮分布式缓存，基于运行时动态的计算哈希值和虚拟节点来进行寻址。数据存储与分布式缓存的不同在于，存储必须保证数据映射的单调性，而缓存则无此要求，所以经典的一致性哈希通常会使用机器 IP 等作为参数来进行哈希，这样造成的结果一方面是数据的落点时而发生改变，一方面是负载通常不均衡。因此我们改造了此算法。
我们通过预计算虚拟节点随机数的方法，生成了割环点同实体机器之间的映射表。该映射表最多可支持一千组的集群规模，满足在任意组数情况下，实体机器间割段长度维持差异在 2% 以内；并且增加任意组数 (总组数上限不超过一千组)，变动后的实体机器间的割段长度依然维持差异在 2% 以内。我们将此映射表硬编码，在运行时避免了计算的过程，数据根据键值哈希值寻址时，只要经过一次二分查找即可获取到对应的实体机器的编号。我们在内存层、存储层以及机械硬盘层都采用了这个映射表，保证了数据在各层路由算法的一致。在工程实现方面，我们可以合理使用这个特性来批量合并请求，以降低资源消耗，这在稍后的章节会有详细描述。
组内均衡
组是数据分区的独立单元，是虚拟节点对应的实体单位。组之间是互相独立的。每组由多台物理机器组成，这是 Paxos Group 生效的基本单位。一份数据包括的多份副本分别散落在组内的各台机器上。为了在组内机器上保证负载均衡，我们同样设计了一套算法，规定了数据副本之间的访问优先级，前端会依优先级逐一的请求数据，只要成功获取，即中断这个过程。然后我们再将副本按优先级均匀的散落在组内机器上，如此即可实现组内负载的均衡。
数据迁移
静态映射表是非常灵活的，在不达到组数上限的情况下，可以任意的增加一组或者多组机器。当然这个过程中一些数据的路由映射发生了改变，则就涉及到了历史数据的挪腾。为了在挪腾的过程中不影响服务，保证数据依然可读可写，我们开发出了对前端透明的，基于迁移标志位，通过数据双写和异步挪数据的方式实现的安全的、可回退的数据迁移流程。
最小不变块
存储层和机械硬盘层通过冷数据链接耦合在了一起。因为两层使用了相同的映射表，那么当存储层因扩容而发生迁移时，那么冷数据链接无疑也要重新寻址，进行一轮重新定位。如果我们以单键值为粒度记录冷数据链接和进行冷数据下沉，那么在万亿键值的语境下，效率无疑是低下。因此我们设计了最小不变块的算法，通过两阶段哈希，使用中间的哈希桶聚集数据，将数据键值和冷数据存储层的机器路由隔离开来。通过该算法，我们可以实现：批量的转存冷数据、热数据存储层批量的以块 (block) 为单位记录冷数据链接、当热数据存储层发生扩容时，块 (block) 内的数据不因扩容被打散掉，而可以整体的迁移到新目标机上。
工程实现
糟糕的工程实现可以毁掉一个完美的系统设计，因此，如何在工程实现的过程中，通过技术的手段，提升系统的表现，同样值得重视。
高效缓存
内存层的设计严重依赖存储层数据版本号的高效获取，那自然是版本号请求全落在内存中就可以了。因此，针对这种情况我们为定长的版本号设计了一套极简的、轻量的、行之有效的缓存――内存容量不足以支撑版本号全缓存。
它的数据结构只是一个二维数组，一维用来构建 hash 链，一维用来实现 LRU 链。每次读或者写都需要通过数组内数据的挪动，来进行更新。如此一来，我们就通过千万级数目的 LRU 链群，实现了缓存整体的 LRU 淘汰。它具有定长，可共享内存搭载，进程重启不丢失、内存使用率高等优点。
批量操作
对系统服务器而言，前端访问过来的某个请求，其对应的逻辑操作都是串行的，我们自然可以梳理这个串行流程中的 CPU 消耗点进行优化。然而当主要的瓶颈被逐渐的消灭掉后，CPU 消耗点变得分散，优化效果就变得微乎其微了。因此，我们只能寻找其它突破点。
我们发现在存储引擎、一致性协议算法的实现流程中，逻辑操作步骤多，涉及到网络交互，硬盘读写等过程。因此，我们决定合并不同请求中的相同步骤，实现批量化操作，极大的优化了 CPU 消耗。
合并的代价即是耗时略有增加，我们通过快慢分离，只针对热点数据请求中的逻辑操作进行合并，去掉了耗时中的不稳定因子，减少了耗时抖动。
请求合并
既然单机的逻辑操作性能已经得到了极大的提升，那么前后端的网络交互阶段，包括接入层的打包解包、协议处理等环节，成为了资源的主要消耗点。参考批量操作的经验，我们同样使用批量化的技术来优化性能――即将后台访问过来的单条请求 (Get) 在内存层聚合成一次批量请求 (Batch Get)。
路由收敛
因为每个数据都是根据键值单独进行路由的，如果要进行请求合并，我们就必须确保同一个批量请求内的数据，都会寻址到相同的 Paxos Group 上。因此，我们必须在内存层将落到同一台存储机器上的 Get 请求聚合起来。我们首先在内存层和存储层采用了相同的路由算法，然后将内存层的组数同存储层的组数进行对齐，来完成了这一目标。
相关工作
在设计的阶段，我们充分的调研了业界的各类方案，大到系统的整体架构，小到具体的技术点。各种方案自有应用场景、各有千秋，不能单纯以好坏区别，我们同样基于自己的业务场景，谨慎的选择合适的方案，或者弃而不用。在此尽量叙述。
处理 SNS 类业务生成的数据，业界有多种的冷热分离架构可以参考。我们以 Facebook 的 Cold Storage 系统举例而言，它也是基于冷热分层的想法，设计出了服务它们照片业务数据的存储方案。不同的是它采用了软硬件结合的方法，一方面定制专门的服务器（包括硬盘、电源等）和数据中心，一方面降低冷数据的备份数、增加纠删码等手段。
然而它们的经验我们是无法彻底套用的，主要两种原因：我们可使用的机器机型是固定的，不存在自己定制硬件的条件。同时它处理的是照片这种大 value 的数据。而我们基本上是文本这种类型的小 value 数据。从前文提及的 TB 访问量角度来看，它们处理的数据是容量瓶颈的，而我们处理的是 IO 瓶颈的，可以算是不太冷的冷数据带来的挑战。所以，我们只能实现自己的冷数据管理策略。
同样，业界有诸多关于如何实现数据一致性的方案。包括我们微信自研的 Quorum 协议，它是一种 NWR 协议，采用异步同步的方式实现数据多副本。即然是异步同步，那在多副本达到最终一致，必然存在一个时间差，那么在单机出现离线的情况下，就会有一定概率导致数据的不可用。而我们追求的是在单点故障下，所有的数据都保证强可用性。
因此，我们采用了无主的去中心化的 Paxos Group 实现了这一目标，其中非租约是 PaxosStore 架构的一个创新亮点。在故障时通常系统是抖动的，会有时断时续的状况，常见的租约做法在这种场景下容易出现反复切换主机而导致长期不可用，而 PaxosStore 的非租约结构能够轻松应对，始终提供良好的服务。PaxosStore 核心代码正在整理开源当中，预计四季度会正式发布，同时该项目的底层框架也基于我们已开源的协程库 github.com/libco。
转自“计算机与网络安全”，作者杨平安
0
评论
环信移动客服v5.21已发布，支持客服发送语音消息、语音转文字及支付功能
产品更新 发表了文章 • 167 次浏览 • 2017-06-27 14:03
客服模式
支持客服发送语音消息
Web版客服工作台支持发送语音消息。与app渠道的客户聊天时，客服可以向客户发送语音消息。
点击输入框上方的麦克风按钮，开始录音并发送。每条语音消息最多为60秒，达到60秒后自动发送。
注：发送语音消息功能仅Chrome浏览器在https模式下支持。
管理员模式
语音转文字beta版
Web版客服工作台支持将app、微信、微博渠道的客户的语音消息自动转为文字，并显示在语音消息下方。方便客服快速识别客户的消息内容，并作出回应。
客服模式的会话、待接入、历史会话、客户中心页面，管理员模式的搜索、历史会话、客户中心、当前会话、质量检查页面，均支持显示语音消息对应的文字。
语音转文字功能正在beta测试阶段，如果您希望先行体验，请提供租户ID，并联系环信商务经理。
开通语音转文字功能后，需要进入“管理员模式 > 设置 > 系统开关”页面，打开“启用语音转文字服务”开关。
在线支付
在线支付功能全新上线。支持在web版移动客服工作台购买标准版坐席、对租户进行续费、增购坐席，并查看订单信息。
进入“管理员模式 > 设置 > 企业信息”页面，点击“购买”按钮。
选择“缴费类型”、购买期限，填写坐席数量，确定并支付订单。
目前，只提供标准版坐席的在线支付功能。缴费类型包括：
新购：第一次购买坐席时，请选择“新购”；续费：需要延长租户的到期日，请选择“续费”；增购：在已有坐席的基础上，增加坐席数量，请选择“增购”。
注：增购坐席时，坐席的到期日与租户的到期日一致，我们按比例收取坐席费用。
【优化】客服超时未回复提醒客服
原“客服超时未回复访客端提示”开关更名为“客服超时未回复提示”，并支持设置“提醒客服”和“提醒访客”。
进入“管理员模式 > 设置 >系统开关”页面，对“客服超时未回复提示”的开关进行设置。
“提醒客服”开关打开，客服超时未回复时，会话主动排在进行中会话列表的顶部并标注颜色。
“提醒访客”开关打开，客服超时未回复时，系统自动发送一条提示语给客户。
进行中会话列表提醒示例：
【优化】工作量、工作质量支持导出客服的真实姓名
对客服的工作量、工作质量详情进行导出时，导出文件包含客服的真实姓名，便于识别对应客服，使数据更直观。
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.21
环信移动客服登陆地址http://kefu.easemob.com/ 查看全部
支持客服发送语音消息
Web版客服工作台支持发送语音消息。与app渠道的客户聊天时，客服可以向客户发送语音消息。
点击输入框上方的麦克风按钮，开始录音并发送。每条语音消息最多为60秒，达到60秒后自动发送。
注：发送语音消息功能仅Chrome浏览器在https模式下支持。
管理员模式
语音转文字beta版
Web版客服工作台支持将app、微信、微博渠道的客户的语音消息自动转为文字，并显示在语音消息下方。方便客服快速识别客户的消息内容，并作出回应。
客服模式的会话、待接入、历史会话、客户中心页面，管理员模式的搜索、历史会话、客户中心、当前会话、质量检查页面，均支持显示语音消息对应的文字。
语音转文字功能正在beta测试阶段，如果您希望先行体验，请提供租户ID，并联系环信商务经理。
开通语音转文字功能后，需要进入“管理员模式 > 设置 > 系统开关”页面，打开“启用语音转文字服务”开关。
在线支付
在线支付功能全新上线。支持在web版移动客服工作台购买标准版坐席、对租户进行续费、增购坐席，并查看订单信息。
进入“管理员模式 > 设置 > 企业信息”页面，点击“购买”按钮。
选择“缴费类型”、购买期限，填写坐席数量，确定并支付订单。
目前，只提供标准版坐席的在线支付功能。缴费类型包括：
新购：第一次购买坐席时，请选择“新购”；续费：需要延长租户的到期日，请选择“续费”；增购：在已有坐席的基础上，增加坐席数量，请选择“增购”。
注：增购坐席时，坐席的到期日与租户的到期日一致，我们按比例收取坐席费用。
【优化】客服超时未回复提醒客服
原“客服超时未回复访客端提示”开关更名为“客服超时未回复提示”，并支持设置“提醒客服”和“提醒访客”。
进入“管理员模式 > 设置 >系统开关”页面，对“客服超时未回复提示”的开关进行设置。
“提醒客服”开关打开，客服超时未回复时，会话主动排在进行中会话列表的顶部并标注颜色。
“提醒访客”开关打开，客服超时未回复时，系统自动发送一条提示语给客户。
进行中会话列表提醒示例：
【优化】工作量、工作质量支持导出客服的真实姓名
对客服的工作量、工作质量详情进行导出时，导出文件包含客服的真实姓名，便于识别对应客服，使数据更直观。
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.21
环信移动客服登陆地址http://kefu.easemob.com/ 查看全部
客服模式
支持客服发送语音消息
Web版客服工作台支持发送语音消息。与app渠道的客户聊天时，客服可以向客户发送语音消息。
点击输入框上方的麦克风按钮，开始录音并发送。每条语音消息最多为60秒，达到60秒后自动发送。
注：发送语音消息功能仅Chrome浏览器在https模式下支持。
管理员模式
语音转文字beta版
Web版客服工作台支持将app、微信、微博渠道的客户的语音消息自动转为文字，并显示在语音消息下方。方便客服快速识别客户的消息内容，并作出回应。
客服模式的会话、待接入、历史会话、客户中心页面，管理员模式的搜索、历史会话、客户中心、当前会话、质量检查页面，均支持显示语音消息对应的文字。
语音转文字功能正在beta测试阶段，如果您希望先行体验，请提供租户ID，并联系环信商务经理。
开通语音转文字功能后，需要进入“管理员模式 > 设置 > 系统开关”页面，打开“启用语音转文字服务”开关。
在线支付
在线支付功能全新上线。支持在web版移动客服工作台购买标准版坐席、对租户进行续费、增购坐席，并查看订单信息。
进入“管理员模式 > 设置 > 企业信息”页面，点击“购买”按钮。
选择“缴费类型”、购买期限，填写坐席数量，确定并支付订单。
目前，只提供标准版坐席的在线支付功能。缴费类型包括：
注：增购坐席时，坐席的到期日与租户的到期日一致，我们按比例收取坐席费用。
【优化】客服超时未回复提醒客服
原“客服超时未回复访客端提示”开关更名为“客服超时未回复提示”，并支持设置“提醒客服”和“提醒访客”。
进入“管理员模式 > 设置 >系统开关”页面，对“客服超时未回复提示”的开关进行设置。
“提醒客服”开关打开，客服超时未回复时，会话主动排在进行中会话列表的顶部并标注颜色。
“提醒访客”开关打开，客服超时未回复时，系统自动发送一条提示语给客户。
进行中会话列表提醒示例：
【优化】工作量、工作质量支持导出客服的真实姓名
对客服的工作量、工作质量详情进行导出时，导出文件包含客服的真实姓名，便于识别对应客服，使数据更直观。
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.21
环信移动客服登陆地址http://kefu.easemob.com/
支持客服发送语音消息
Web版客服工作台支持发送语音消息。与app渠道的客户聊天时，客服可以向客户发送语音消息。
点击输入框上方的麦克风按钮，开始录音并发送。每条语音消息最多为60秒，达到60秒后自动发送。
注：发送语音消息功能仅Chrome浏览器在https模式下支持。
管理员模式
语音转文字beta版
Web版客服工作台支持将app、微信、微博渠道的客户的语音消息自动转为文字，并显示在语音消息下方。方便客服快速识别客户的消息内容，并作出回应。
客服模式的会话、待接入、历史会话、客户中心页面，管理员模式的搜索、历史会话、客户中心、当前会话、质量检查页面，均支持显示语音消息对应的文字。
语音转文字功能正在beta测试阶段，如果您希望先行体验，请提供租户ID，并联系环信商务经理。
开通语音转文字功能后，需要进入“管理员模式 > 设置 > 系统开关”页面，打开“启用语音转文字服务”开关。
在线支付
在线支付功能全新上线。支持在web版移动客服工作台购买标准版坐席、对租户进行续费、增购坐席，并查看订单信息。
进入“管理员模式 > 设置 > 企业信息”页面，点击“购买”按钮。
选择“缴费类型”、购买期限，填写坐席数量，确定并支付订单。
目前，只提供标准版坐席的在线支付功能。缴费类型包括：
- 新购：第一次购买坐席时，请选择“新购”；
- 续费：需要延长租户的到期日，请选择“续费”；
- 增购：在已有坐席的基础上，增加坐席数量，请选择“增购”。
注：增购坐席时，坐席的到期日与租户的到期日一致，我们按比例收取坐席费用。
【优化】客服超时未回复提醒客服
原“客服超时未回复访客端提示”开关更名为“客服超时未回复提示”，并支持设置“提醒客服”和“提醒访客”。
进入“管理员模式 > 设置 >系统开关”页面，对“客服超时未回复提示”的开关进行设置。
“提醒客服”开关打开，客服超时未回复时，会话主动排在进行中会话列表的顶部并标注颜色。
“提醒访客”开关打开，客服超时未回复时，系统自动发送一条提示语给客户。
进行中会话列表提醒示例：
【优化】工作量、工作质量支持导出客服的真实姓名
对客服的工作量、工作质量详情进行导出时，导出文件包含客服的真实姓名，便于识别对应客服，使数据更直观。
环信移动客服更新日志http://docs.easemob.com/cs/releasenote/5.21
环信移动客服登陆地址http://kefu.easemob.com/
0
回复
0
评论
【环信公开课第14期视频回放】情感计算：如何用人工智能解读人类“情感”
beyond 发表了文章 • 2650 次浏览 • 2017-06-27 11:52
朱泙漫学屠龙于支离益 ， 殚千金之家，三年技成而无所用其巧。
——《庄子·列御寇》
6月25日，EmoKit创始人兼CEO魏清晨在环信公开课上以“情感计算”为主题做了人工智能解读人类“情感”的分享。魏清晨称，机器人未必像人的形态一样，有胳膊、有腿、有眼睛、有嘴，但如果要让机器实现真正智能，并且跟我们产生自然而然的交互，需要具备情绪识别和表达的能力。
魏清晨讲到， EmoKit主要专注于机器人情感的研发，让机器人从一个多模态的形式了解人的情感，从渠道数据来源的角度去做综合判断，可以预见的未来，曾经独属于人类的情感将“赋能”人工智能！
公开课课程大纲
情感计算概述与发展
情绪是人类社会奖惩机制最底层的编码情感计算包含的模块和价值情感计算，是人工智能的下一个未来情感计算的技术实现
情感信号的获取与量化
分析、建模与识别情感理解和反馈情感合成与表达人机交互的实现
AI+情感计算的应用
情感计算在环信IM的最佳实践环信客服通过情感计算实现智能质检更多落地场景商业变现
AI火爆背景下的冷思考
视频回放
已有8625名开发者加入环信公开课，妹子比例10%！还有最强王者等你开黑！赶紧加入我们一起玩耍吧！
查看全部
——《庄子·列御寇》
6月25日，EmoKit创始人兼CEO魏清晨在环信公开课上以“情感计算”为主题做了人工智能解读人类“情感”的分享。魏清晨称，机器人未必像人的形态一样，有胳膊、有腿、有眼睛、有嘴，但如果要让机器实现真正智能，并且跟我们产生自然而然的交互，需要具备情绪识别和表达的能力。
魏清晨讲到， EmoKit主要专注于机器人情感的研发，让机器人从一个多模态的形式了解人的情感，从渠道数据来源的角度去做综合判断，可以预见的未来，曾经独属于人类的情感将“赋能”人工智能！
公开课课程大纲
情感计算概述与发展
情绪是人类社会奖惩机制最底层的编码情感计算包含的模块和价值情感计算，是人工智能的下一个未来情感计算的技术实现
情感信号的获取与量化
分析、建模与识别情感理解和反馈情感合成与表达人机交互的实现
AI+情感计算的应用
情感计算在环信IM的最佳实践环信客服通过情感计算实现智能质检更多落地场景商业变现
AI火爆背景下的冷思考
视频回放
已有8625名开发者加入环信公开课，妹子比例10%！还有最强王者等你开黑！赶紧加入我们一起玩耍吧！
查看全部
朱泙漫学屠龙于支离益 ， 殚千金之家，三年技成而无所用其巧。
——《庄子·列御寇》
6月25日，EmoKit创始人兼CEO魏清晨在环信公开课上以“情感计算”为主题做了人工智能解读人类“情感”的分享。魏清晨称，机器人未必像人的形态一样，有胳膊、有腿、有眼睛、有嘴，但如果要让机器实现真正智能，并且跟我们产生自然而然的交互，需要具备情绪识别和表达的能力。
魏清晨讲到， EmoKit主要专注于机器人情感的研发，让机器人从一个多模态的形式了解人的情感，从渠道数据来源的角度去做综合判断，可以预见的未来，曾经独属于人类的情感将“赋能”人工智能！
公开课课程大纲
- 情感计算概述与发展
- 情绪是人类社会奖惩机制最底层的编码
- 情感计算包含的模块和价值
- 情感计算，是人工智能的下一个未来
- 情感计算的技术实现
- 情感信号的获取与量化
- 分析、建模与识别
- 情感理解和反馈
- 情感合成与表达
- 人机交互的实现
- AI+情感计算的应用
- 情感计算在环信IM的最佳实践
- 环信客服通过情感计算实现智能质检
- 更多落地场景
- 商业变现
- AI火爆背景下的冷思考
视频回放
已有8625名开发者加入环信公开课，妹子比例10%！还有最强王者等你开黑！赶紧加入我们一起玩耍吧！
0
评论
《IT经理世界》特写：环信的Alpha刘，布局未来的商业智能！
新闻资讯 发表了文章 • 140 次浏览 • 2017-06-27 11:21
6月20号刊
新疆界
刘俊彦说不想做一家小老头公司——规模不大，每年挣个几千万元，日子过得滋润，但每年只有10%左右的增长。
技术男刘俊彦的思维很跳跃，2014年做即时通讯云，一年后开始做客服云，不到一年，又开辟了智能机器人业务。看起来好像在分片作战，但突然有一天他已经在一个更大的战略布局里了。
这些年，云的概念被炒到火热，企业不惜花血本布局云计算，可一轮下来之后，不同的业务还是要各养一套人马，各养一套软件系统，说好的大数据，量是上去了，但是实际利用率却如挤牙膏，效用微乎其微。很多企业现在正处在一个升级也不是，不升级也不是的难受期。
见到刘俊彦的时候，他刚送走一家航空公司的几位管理人员，他们现在的烦恼是，守着一大批高净值的用户，只能卖个机票，最多再卖个保险，利润已经碰到天花板，有种守着宝藏却挖不出金子的感觉。刘俊彦在他的小会议室的黑板上，画了一个完整的从用户服务到用户营销的闭环图，这张图里包含了航空公司乃至一些大企业当下的几大痛点及应对招数，如同在下一盘围棋，细节处棋势做得够厚，大局又跳出常人思维之外，细看与AlphaGo的风格颇为相似。
这是刘俊彦第一次将自己成熟的大局想法展示给外界。
高效融资与快速换挡
刘俊彦毕业于英国伦敦大学国王学院计算机专业，后一直在IT外企从事技术研发工作，2013年，离职创业前已经成为红帽开源软件领域领先的专家。这一年，他已经年过40。
最初的一年多时间，是在海淀图书城的车库咖啡里度过的，当时刘俊彦和另外三位合伙人都刚从外企里出来，各自都已经是行业里优秀的技术人才，都实现了财务自由，清楚自己要的是什么，且志趣相投，所以走到了一起。
刚开始，大家专注于做产品，也没有急着去找投资。一年后，一个偶然的机会，投资自己找上了门。
2014年5月，刘俊彦他们进驻到氪空间的当天下午，经纬的投资人找到了他们，大概聊了两个多小时，双方就达成了合作意向。紧接着不到半年，SIG和红杉资本相继成为投资方。几家投资方看中的是刘俊彦等人创立的环信公司在即时通讯领域的开发能力和社交大数据分析能力，以及环信自主研发的高并发可扩展架构。
此前，刘俊彦拥有17年的开发经验，其擅长的领域在于实时消息系统和高并发消息中间件等。2013年，社交软件开始大行其道，当时很多人找他为APP开发即时通讯聊天功能，一般如果企业自己开发的话，怎么都需要好几个月时间，而使用刘俊彦的团队的产品只需一天功夫就出来了。因此，最初的产品并非他们刻意做出来的，而是需求在先，而且令他们也没想到的是，做着做着就成“风口”了。
很快，使用了环信即时通讯功能的APP上的用户从几万飞速上升到几千万，乃至后来的几个亿，每天下发的消息达20亿条。曾经在短信高峰时代，中国移动每天的消息量是7亿，目前国内能支撑并发连接几千万的团队不超过5个，包括腾讯、阿里、新浪微博、陌陌等，另外还有一个就是环信。
用户上去之后，新的需求又来了。开始，很多人只是把APP内的聊天功能用作连接人与人的社交管道，但很快就不断有人找上门来，希望把APP内的聊天功能做成淘宝旺旺那样连接人和商业的客服工具。
从本质上来讲，环信早期推出的即时通讯云是基于PaaS平台的服务，而要做客服云则需建立在SaaS平台上，如此跨平台的转变，对于一家创业公司，无论是人才、资本、研发或渠道等各方面都会带来严峻的挑战。
2015年4月，A轮的三家投资方在前几个轮次共900万美元的基础上，再次追加了共1250万美元的B轮投资，在资本方的财力和战略加持下，一个月后，环信客服产品线上市，一年后环信客服产品的客户量、销售额等硬指标均达到几十倍上百倍的增长。
据刘俊彦介绍，早期客服云的客户几乎一半多来自即时通讯云，相当于后者是前者的流量导入渠道，后者反过来巩固了前者的价值所在。
目前，环信客服产品的企业用户已经超过5万多家，用户也从国美在线、58到家、新东方等扩展到了十几个行业当中。
然而，IT业一年相当于传统行业十年，这是一个变换以秒速推进的行业，刘俊彦很快又迎上了新的挑战。
痛点与前瞻
随着产品的积累和行业的扩展，刘俊彦开始接触到一些保险、证券、航空等行业大客户。曾经有一家保险公司的客户跟他提到亲身经历的一件事情，以往保险公司客户经理做客户维护的通常做法就是每年会定期提前一两个月给老客户打电话，提醒他们保险快到期，可以续费了。其中有一个老客户，关系维护得挺好，但是这个老客户最近新买了辆哈雷摩托车，而他的客户经理没能及时了解并提供摩托车的保险报价，结果错失了老用户。
这种个案在保险公司普遍存在。如果有更懂用户的数据，进行再分析和精准营销，就能很快帮老用户接上新的业务，还可以把以前让利给渠道的部分，直接反馈给用户，大幅提高销售成功率。
刘俊彦说，做即时通讯，做客服，真正的差距在于，怎么通过商业智能帮助企业去挖掘以前看不到的客户信息，提高销售转换率，发掘新销售机会，以及人工智能技术怎么代替人工，怎么帮企业营销，这都是未来技术。
2016年年初，环信基于企业一体化智能商业的需求，开始推全媒体智能客户服务。所谓全媒体就是不管客服请求来自微信、微博或APP，还是网页或电话，都可以同时呈现在一个界面上，由专人统一处理。
以前企业不同的渠道由不同的人马在支持，各自软件系统也不一样，信息也是各自孤立的，片段化的，环信做到了让一个支持人员同时监控所有渠道，客户身份也可以从孤立的信息中关联起来，形成一个统一身份。也就是说，同一个用户打完电话，再用微信接入，通过各种技术方法可以跨屏身份合并被识别为是同一个人。
此外，一家企业如果每天进来10万条消息，环信的技术可以识别出来自不同渠道不同数据格式的信息，然后对其进行数据清理，再做主题分析和情感分析，从而知道用户今天都反馈了什么问题，情感是愤怒还是高兴，可能的消费趋势是什么？进一步还可以給出用户画像，画像信息详尽，一直可追溯到用户城市、职业、性别、喜好、消费能力、行为轨迹，等等。
这些数据对于企业至关重要。不仅是保险公司，证券公司、航空公司等等行业都存在类似的强烈需求。
环信还在自己研发客服机器人。刘俊彦认为，环信既有SaaS客服软件高市场占有率的通道优势，又有了大量的数据积累，加上对垂直行业的深度理解，在开发具有高度行业特征的客服机器人上，又领先了其他对手。
2017年 ，环信整合旗下即时通信云、移动客服、智能客服机器人和主动营销产品线，推出环信CEC (Customer Engagement Cloud)，向企业提供从客户互动渠道，到客户服务，再到精准客户营销的全流程客户互动解决方案。
技术出身的刘俊彦，既可以不断挖掘出用户的痛点，在技术细节上下足功夫，又可以跳出来，把握住前瞻性技术，果断出击。当一个个看似不大相关的痛点技术在量的积累上突破一个爆发性临界点时，全新的需求与应用又把之前所有的技术关联在了一起。
这一切使得刘俊彦像一个“做局”的高手。
转变与坚持
创业仅仅4年，刘俊彦已经看惯了互联网领域的迎来送往，2014年，他还经常在微信里看见做社交应用的CEO们发朋友圈，到2015年左右，这些人大多看不到了，换了一批做O2O的CEO，一年以后，这些人又看不见踪影了。大浪淘沙，互联网的残酷淘汰是铁律。
当年那些做即时通讯服务的环信的老对手们，现在大多还在做老业务，日子过得还不错。刘俊彦却早已不在当初的格局里了。
做即时通讯云有一个特点，从几十万用户到几百万用户是一个技术节点，从几百万到几千万又是一个节点，用户过亿之后则是一个更大的节点。每一个节点处，基本上架构要推倒重写一遍。这要求技术团队快速的迭代和积累，一旦有一个环节出问题，就有可能导致服务不可用。
这期间，环信团队也经历了重大考验，也被客户骂过，好在最后都坚持过来了。现在环信即时通讯技术架构早已稳定下来，即使再扩容4～5倍也不成问题。
然而，就在这么一个节点上，刘俊彦毅然决定再另外做一个SaaS平台，这对于整个团队是一种怎样的震撼。虽然对于技术能力强悍的环信团队来讲，技术难题最终都是可以克服的，而对市场的敏锐嗅觉以及果断决策，却非易事。事实上刘俊彦的判断是精准的。
环信最初的客户群主要集中在互联网领域，这些客户的生命周期比较短，付费能力比较低，好处是决策周期短，商业谈判简单，能迅速达成交易，迅速验证需求，这适合早期创业。
有了这段经历也让刘俊彦开始明白，为什么美国的SaaS软件同行们天天讲生命周期价值，讲内容营销，因为他们也跟环信一样做的是小客户，可见对于小客户这一招中外通吃。而大客户不是这么玩的。
在美国做企业服务，底层有一批创业公司，天花板是做到几亿美元到几十亿美元市值，基本很难再往上突破了。这是因为大客户都被微软、甲骨文、Salesforce这样的公司牢牢掌握着，小企业根本没机会进入那个圈子。
某种程度上，中国也差不多，但也有很大不同。中国大型企业还没有强大的科技公司可以很好地服务于他们，这些年主要依赖于一些大型系统集成商，系统集成商的做法跟甲骨文等这些科技巨头又不一样，他们以项目运行的方式推进，在创新和积累上相对较弱。
以前中国的大型国企或私企也认可这种做法，但随着整体经济环境进入L型经济，增长放缓，企业追求利润的结果就是更加注重创新，尤其是服务创新，这两年刘俊彦明显地感觉到国内大型企业有一种创新急迫感，他意识到谁能服务中国500强企业，谁就会成为中国的甲骨文。
由于求稳，当年环信的竞争对手就没赶上这波新的机会。“如果我们到现在还只是在做最初的一个业务，我们也就成为了一家小老头公司。”刘俊彦平静地说。
2017年3月，环信完成1.03亿元的C轮融资，由经纬领投，银泰嘉禾跟投。
当然，考验仍然存在。SaaS是一种功能密集型的技术，最考验大规模研发团队的研发效率和管理能力。2016年新组建的智能机器人团队则是资本密集型，这个团队虽然人不多，但是一年投入却上千万元。
不同的技术、人才、资本结构，对于管理是一大考验。不过刘俊彦认为，既然创业就要全力以赴去做，“挖人要看眼光，选择很重要，路线很重要，信任也很重要，既然选择上了火箭飞船，就不要考虑是几等舱。”
作者 | 刘晓芳
微信编辑 | 李昊原
原文发表于《IT经理世界》，转载请注明 查看全部
新疆界
刘俊彦说不想做一家小老头公司——规模不大，每年挣个几千万元，日子过得滋润，但每年只有10%左右的增长。
技术男刘俊彦的思维很跳跃，2014年做即时通讯云，一年后开始做客服云，不到一年，又开辟了智能机器人业务。看起来好像在分片作战，但突然有一天他已经在一个更大的战略布局里了。
这些年，云的概念被炒到火热，企业不惜花血本布局云计算，可一轮下来之后，不同的业务还是要各养一套人马，各养一套软件系统，说好的大数据，量是上去了，但是实际利用率却如挤牙膏，效用微乎其微。很多企业现在正处在一个升级也不是，不升级也不是的难受期。
见到刘俊彦的时候，他刚送走一家航空公司的几位管理人员，他们现在的烦恼是，守着一大批高净值的用户，只能卖个机票，最多再卖个保险，利润已经碰到天花板，有种守着宝藏却挖不出金子的感觉。刘俊彦在他的小会议室的黑板上，画了一个完整的从用户服务到用户营销的闭环图，这张图里包含了航空公司乃至一些大企业当下的几大痛点及应对招数，如同在下一盘围棋，细节处棋势做得够厚，大局又跳出常人思维之外，细看与AlphaGo的风格颇为相似。
这是刘俊彦第一次将自己成熟的大局想法展示给外界。
高效融资与快速换挡
刘俊彦毕业于英国伦敦大学国王学院计算机专业，后一直在IT外企从事技术研发工作，2013年，离职创业前已经成为红帽开源软件领域领先的专家。这一年，他已经年过40。
最初的一年多时间，是在海淀图书城的车库咖啡里度过的，当时刘俊彦和另外三位合伙人都刚从外企里出来，各自都已经是行业里优秀的技术人才，都实现了财务自由，清楚自己要的是什么，且志趣相投，所以走到了一起。
刚开始，大家专注于做产品，也没有急着去找投资。一年后，一个偶然的机会，投资自己找上了门。
2014年5月，刘俊彦他们进驻到氪空间的当天下午，经纬的投资人找到了他们，大概聊了两个多小时，双方就达成了合作意向。紧接着不到半年，SIG和红杉资本相继成为投资方。几家投资方看中的是刘俊彦等人创立的环信公司在即时通讯领域的开发能力和社交大数据分析能力，以及环信自主研发的高并发可扩展架构。
此前，刘俊彦拥有17年的开发经验，其擅长的领域在于实时消息系统和高并发消息中间件等。2013年，社交软件开始大行其道，当时很多人找他为APP开发即时通讯聊天功能，一般如果企业自己开发的话，怎么都需要好几个月时间，而使用刘俊彦的团队的产品只需一天功夫就出来了。因此，最初的产品并非他们刻意做出来的，而是需求在先，而且令他们也没想到的是，做着做着就成“风口”了。
很快，使用了环信即时通讯功能的APP上的用户从几万飞速上升到几千万，乃至后来的几个亿，每天下发的消息达20亿条。曾经在短信高峰时代，中国移动每天的消息量是7亿，目前国内能支撑并发连接几千万的团队不超过5个，包括腾讯、阿里、新浪微博、陌陌等，另外还有一个就是环信。
用户上去之后，新的需求又来了。开始，很多人只是把APP内的聊天功能用作连接人与人的社交管道，但很快就不断有人找上门来，希望把APP内的聊天功能做成淘宝旺旺那样连接人和商业的客服工具。
从本质上来讲，环信早期推出的即时通讯云是基于PaaS平台的服务，而要做客服云则需建立在SaaS平台上，如此跨平台的转变，对于一家创业公司，无论是人才、资本、研发或渠道等各方面都会带来严峻的挑战。
2015年4月，A轮的三家投资方在前几个轮次共900万美元的基础上，再次追加了共1250万美元的B轮投资，在资本方的财力和战略加持下，一个月后，环信客服产品线上市，一年后环信客服产品的客户量、销售额等硬指标均达到几十倍上百倍的增长。
据刘俊彦介绍，早期客服云的客户几乎一半多来自即时通讯云，相当于后者是前者的流量导入渠道，后者反过来巩固了前者的价值所在。
目前，环信客服产品的企业用户已经超过5万多家，用户也从国美在线、58到家、新东方等扩展到了十几个行业当中。
然而，IT业一年相当于传统行业十年，这是一个变换以秒速推进的行业，刘俊彦很快又迎上了新的挑战。
痛点与前瞻
随着产品的积累和行业的扩展，刘俊彦开始接触到一些保险、证券、航空等行业大客户。曾经有一家保险公司的客户跟他提到亲身经历的一件事情，以往保险公司客户经理做客户维护的通常做法就是每年会定期提前一两个月给老客户打电话，提醒他们保险快到期，可以续费了。其中有一个老客户，关系维护得挺好，但是这个老客户最近新买了辆哈雷摩托车，而他的客户经理没能及时了解并提供摩托车的保险报价，结果错失了老用户。
这种个案在保险公司普遍存在。如果有更懂用户的数据，进行再分析和精准营销，就能很快帮老用户接上新的业务，还可以把以前让利给渠道的部分，直接反馈给用户，大幅提高销售成功率。
刘俊彦说，做即时通讯，做客服，真正的差距在于，怎么通过商业智能帮助企业去挖掘以前看不到的客户信息，提高销售转换率，发掘新销售机会，以及人工智能技术怎么代替人工，怎么帮企业营销，这都是未来技术。
2016年年初，环信基于企业一体化智能商业的需求，开始推全媒体智能客户服务。所谓全媒体就是不管客服请求来自微信、微博或APP，还是网页或电话，都可以同时呈现在一个界面上，由专人统一处理。
以前企业不同的渠道由不同的人马在支持，各自软件系统也不一样，信息也是各自孤立的，片段化的，环信做到了让一个支持人员同时监控所有渠道，客户身份也可以从孤立的信息中关联起来，形成一个统一身份。也就是说，同一个用户打完电话，再用微信接入，通过各种技术方法可以跨屏身份合并被识别为是同一个人。
此外，一家企业如果每天进来10万条消息，环信的技术可以识别出来自不同渠道不同数据格式的信息，然后对其进行数据清理，再做主题分析和情感分析，从而知道用户今天都反馈了什么问题，情感是愤怒还是高兴，可能的消费趋势是什么？进一步还可以給出用户画像，画像信息详尽，一直可追溯到用户城市、职业、性别、喜好、消费能力、行为轨迹，等等。
这些数据对于企业至关重要。不仅是保险公司，证券公司、航空公司等等行业都存在类似的强烈需求。
环信还在自己研发客服机器人。刘俊彦认为，环信既有SaaS客服软件高市场占有率的通道优势，又有了大量的数据积累，加上对垂直行业的深度理解，在开发具有高度行业特征的客服机器人上，又领先了其他对手。
2017年 ，环信整合旗下即时通信云、移动客服、智能客服机器人和主动营销产品线，推出环信CEC (Customer Engagement Cloud)，向企业提供从客户互动渠道，到客户服务，再到精准客户营销的全流程客户互动解决方案。
技术出身的刘俊彦，既可以不断挖掘出用户的痛点，在技术细节上下足功夫，又可以跳出来，把握住前瞻性技术，果断出击。当一个个看似不大相关的痛点技术在量的积累上突破一个爆发性临界点时，全新的需求与应用又把之前所有的技术关联在了一起。
这一切使得刘俊彦像一个“做局”的高手。
转变与坚持
创业仅仅4年，刘俊彦已经看惯了互联网领域的迎来送往，2014年，他还经常在微信里看见做社交应用的CEO们发朋友圈，到2015年左右，这些人大多看不到了，换了一批做O2O的CEO，一年以后，这些人又看不见踪影了。大浪淘沙，互联网的残酷淘汰是铁律。
当年那些做即时通讯服务的环信的老对手们，现在大多还在做老业务，日子过得还不错。刘俊彦却早已不在当初的格局里了。
做即时通讯云有一个特点，从几十万用户到几百万用户是一个技术节点，从几百万到几千万又是一个节点，用户过亿之后则是一个更大的节点。每一个节点处，基本上架构要推倒重写一遍。这要求技术团队快速的迭代和积累，一旦有一个环节出问题，就有可能导致服务不可用。
这期间，环信团队也经历了重大考验，也被客户骂过，好在最后都坚持过来了。现在环信即时通讯技术架构早已稳定下来，即使再扩容4～5倍也不成问题。
然而，就在这么一个节点上，刘俊彦毅然决定再另外做一个SaaS平台，这对于整个团队是一种怎样的震撼。虽然对于技术能力强悍的环信团队来讲，技术难题最终都是可以克服的，而对市场的敏锐嗅觉以及果断决策，却非易事。事实上刘俊彦的判断是精准的。
环信最初的客户群主要集中在互联网领域，这些客户的生命周期比较短，付费能力比较低，好处是决策周期短，商业谈判简单，能迅速达成交易，迅速验证需求，这适合早期创业。
有了这段经历也让刘俊彦开始明白，为什么美国的SaaS软件同行们天天讲生命周期价值，讲内容营销，因为他们也跟环信一样做的是小客户，可见对于小客户这一招中外通吃。而大客户不是这么玩的。
在美国做企业服务，底层有一批创业公司，天花板是做到几亿美元到几十亿美元市值，基本很难再往上突破了。这是因为大客户都被微软、甲骨文、Salesforce这样的公司牢牢掌握着，小企业根本没机会进入那个圈子。
某种程度上，中国也差不多，但也有很大不同。中国大型企业还没有强大的科技公司可以很好地服务于他们，这些年主要依赖于一些大型系统集成商，系统集成商的做法跟甲骨文等这些科技巨头又不一样，他们以项目运行的方式推进，在创新和积累上相对较弱。
以前中国的大型国企或私企也认可这种做法，但随着整体经济环境进入L型经济，增长放缓，企业追求利润的结果就是更加注重创新，尤其是服务创新，这两年刘俊彦明显地感觉到国内大型企业有一种创新急迫感，他意识到谁能服务中国500强企业，谁就会成为中国的甲骨文。
由于求稳，当年环信的竞争对手就没赶上这波新的机会。“如果我们到现在还只是在做最初的一个业务，我们也就成为了一家小老头公司。”刘俊彦平静地说。
2017年3月，环信完成1.03亿元的C轮融资，由经纬领投，银泰嘉禾跟投。
当然，考验仍然存在。SaaS是一种功能密集型的技术，最考验大规模研发团队的研发效率和管理能力。2016年新组建的智能机器人团队则是资本密集型，这个团队虽然人不多，但是一年投入却上千万元。
不同的技术、人才、资本结构，对于管理是一大考验。不过刘俊彦认为，既然创业就要全力以赴去做，“挖人要看眼光，选择很重要，路线很重要，信任也很重要，既然选择上了火箭飞船，就不要考虑是几等舱。”
作者 | 刘晓芳
微信编辑 | 李昊原
原文发表于《IT经理世界》，转载请注明 查看全部
6月20号刊
新疆界
刘俊彦说不想做一家小老头公司——规模不大，每年挣个几千万元，日子过得滋润，但每年只有10%左右的增长。
技术男刘俊彦的思维很跳跃，2014年做即时通讯云，一年后开始做客服云，不到一年，又开辟了智能机器人业务。看起来好像在分片作战，但突然有一天他已经在一个更大的战略布局里了。
这些年，云的概念被炒到火热，企业不惜花血本布局云计算，可一轮下来之后，不同的业务还是要各养一套人马，各养一套软件系统，说好的大数据，量是上去了，但是实际利用率却如挤牙膏，效用微乎其微。很多企业现在正处在一个升级也不是，不升级也不是的难受期。
见到刘俊彦的时候，他刚送走一家航空公司的几位管理人员，他们现在的烦恼是，守着一大批高净值的用户，只能卖个机票，最多再卖个保险，利润已经碰到天花板，有种守着宝藏却挖不出金子的感觉。刘俊彦在他的小会议室的黑板上，画了一个完整的从用户服务到用户营销的闭环图，这张图里包含了航空公司乃至一些大企业当下的几大痛点及应对招数，如同在下一盘围棋，细节处棋势做得够厚，大局又跳出常人思维之外，细看与AlphaGo的风格颇为相似。
这是刘俊彦第一次将自己成熟的大局想法展示给外界。
高效融资与快速换挡
刘俊彦毕业于英国伦敦大学国王学院计算机专业，后一直在IT外企从事技术研发工作，2013年，离职创业前已经成为红帽开源软件领域领先的专家。这一年，他已经年过40。
最初的一年多时间，是在海淀图书城的车库咖啡里度过的，当时刘俊彦和另外三位合伙人都刚从外企里出来，各自都已经是行业里优秀的技术人才，都实现了财务自由，清楚自己要的是什么，且志趣相投，所以走到了一起。
刚开始，大家专注于做产品，也没有急着去找投资。一年后，一个偶然的机会，投资自己找上了门。
2014年5月，刘俊彦他们进驻到氪空间的当天下午，经纬的投资人找到了他们，大概聊了两个多小时，双方就达成了合作意向。紧接着不到半年，SIG和红杉资本相继成为投资方。几家投资方看中的是刘俊彦等人创立的环信公司在即时通讯领域的开发能力和社交大数据分析能力，以及环信自主研发的高并发可扩展架构。
此前，刘俊彦拥有17年的开发经验，其擅长的领域在于实时消息系统和高并发消息中间件等。2013年，社交软件开始大行其道，当时很多人找他为APP开发即时通讯聊天功能，一般如果企业自己开发的话，怎么都需要好几个月时间，而使用刘俊彦的团队的产品只需一天功夫就出来了。因此，最初的产品并非他们刻意做出来的，而是需求在先，而且令他们也没想到的是，做着做着就成“风口”了。
很快，使用了环信即时通讯功能的APP上的用户从几万飞速上升到几千万，乃至后来的几个亿，每天下发的消息达20亿条。曾经在短信高峰时代，中国移动每天的消息量是7亿，目前国内能支撑并发连接几千万的团队不超过5个，包括腾讯、阿里、新浪微博、陌陌等，另外还有一个就是环信。
用户上去之后，新的需求又来了。开始，很多人只是把APP内的聊天功能用作连接人与人的社交管道，但很快就不断有人找上门来，希望把APP内的聊天功能做成淘宝旺旺那样连接人和商业的客服工具。
从本质上来讲，环信早期推出的即时通讯云是基于PaaS平台的服务，而要做客服云则需建立在SaaS平台上，如此跨平台的转变，对于一家创业公司，无论是人才、资本、研发或渠道等各方面都会带来严峻的挑战。
2015年4月，A轮的三家投资方在前几个轮次共900万美元的基础上，再次追加了共1250万美元的B轮投资，在资本方的财力和战略加持下，一个月后，环信客服产品线上市，一年后环信客服产品的客户量、销售额等硬指标均达到几十倍上百倍的增长。
据刘俊彦介绍，早期客服云的客户几乎一半多来自即时通讯云，相当于后者是前者的流量导入渠道，后者反过来巩固了前者的价值所在。
目前，环信客服产品的企业用户已经超过5万多家，用户也从国美在线、58到家、新东方等扩展到了十几个行业当中。
然而，IT业一年相当于传统行业十年，这是一个变换以秒速推进的行业，刘俊彦很快又迎上了新的挑战。
痛点与前瞻
随着产品的积累和行业的扩展，刘俊彦开始接触到一些保险、证券、航空等行业大客户。曾经有一家保险公司的客户跟他提到亲身经历的一件事情，以往保险公司客户经理做客户维护的通常做法就是每年会定期提前一两个月给老客户打电话，提醒他们保险快到期，可以续费了。其中有一个老客户，关系维护得挺好，但是这个老客户最近新买了辆哈雷摩托车，而他的客户经理没能及时了解并提供摩托车的保险报价，结果错失了老用户。
这种个案在保险公司普遍存在。如果有更懂用户的数据，进行再分析和精准营销，就能很快帮老用户接上新的业务，还可以把以前让利给渠道的部分，直接反馈给用户，大幅提高销售成功率。
刘俊彦说，做即时通讯，做客服，真正的差距在于，怎么通过商业智能帮助企业去挖掘以前看不到的客户信息，提高销售转换率，发掘新销售机会，以及人工智能技术怎么代替人工，怎么帮企业营销，这都是未来技术。
2016年年初，环信基于企业一体化智能商业的需求，开始推全媒体智能客户服务。所谓全媒体就是不管客服请求来自微信、微博或APP，还是网页或电话，都可以同时呈现在一个界面上，由专人统一处理。
以前企业不同的渠道由不同的人马在支持，各自软件系统也不一样，信息也是各自孤立的，片段化的，环信做到了让一个支持人员同时监控所有渠道，客户身份也可以从孤立的信息中关联起来，形成一个统一身份。也就是说，同一个用户打完电话，再用微信接入，通过各种技术方法可以跨屏身份合并被识别为是同一个人。
此外，一家企业如果每天进来10万条消息，环信的技术可以识别出来自不同渠道不同数据格式的信息，然后对其进行数据清理，再做主题分析和情感分析，从而知道用户今天都反馈了什么问题，情感是愤怒还是高兴，可能的消费趋势是什么？进一步还可以給出用户画像，画像信息详尽，一直可追溯到用户城市、职业、性别、喜好、消费能力、行为轨迹，等等。
这些数据对于企业至关重要。不仅是保险公司，证券公司、航空公司等等行业都存在类似的强烈需求。
环信还在自己研发客服机器人。刘俊彦认为，环信既有SaaS客服软件高市场占有率的通道优势，又有了大量的数据积累，加上对垂直行业的深度理解，在开发具有高度行业特征的客服机器人上，又领先了其他对手。
2017年 ，环信整合旗下即时通信云、移动客服、智能客服机器人和主动营销产品线，推出环信CEC (Customer Engagement Cloud)，向企业提供从客户互动渠道，到客户服务，再到精准客户营销的全流程客户互动解决方案。
技术出身的刘俊彦，既可以不断挖掘出用户的痛点，在技术细节上下足功夫，又可以跳出来，把握住前瞻性技术，果断出击。当一个个看似不大相关的痛点技术在量的积累上突破一个爆发性临界点时，全新的需求与应用又把之前所有的技术关联在了一起。
这一切使得刘俊彦像一个“做局”的高手。
转变与坚持
创业仅仅4年，刘俊彦已经看惯了互联网领域的迎来送往，2014年，他还经常在微信里看见做社交应用的CEO们发朋友圈，到2015年左右，这些人大多看不到了，换了一批做O2O的CEO，一年以后，这些人又看不见踪影了。大浪淘沙，互联网的残酷淘汰是铁律。
当年那些做即时通讯服务的环信的老对手们，现在大多还在做老业务，日子过得还不错。刘俊彦却早已不在当初的格局里了。
做即时通讯云有一个特点，从几十万用户到几百万用户是一个技术节点，从几百万到几千万又是一个节点，用户过亿之后则是一个更大的节点。每一个节点处，基本上架构要推倒重写一遍。这要求技术团队快速的迭代和积累，一旦有一个环节出问题，就有可能导致服务不可用。
这期间，环信团队也经历了重大考验，也被客户骂过，好在最后都坚持过来了。现在环信即时通讯技术架构早已稳定下来，即使再扩容4～5倍也不成问题。
然而，就在这么一个节点上，刘俊彦毅然决定再另外做一个SaaS平台，这对于整个团队是一种怎样的震撼。虽然对于技术能力强悍的环信团队来讲，技术难题最终都是可以克服的，而对市场的敏锐嗅觉以及果断决策，却非易事。事实上刘俊彦的判断是精准的。
环信最初的客户群主要集中在互联网领域，这些客户的生命周期比较短，付费能力比较低，好处是决策周期短，商业谈判简单，能迅速达成交易，迅速验证需求，这适合早期创业。
有了这段经历也让刘俊彦开始明白，为什么美国的SaaS软件同行们天天讲生命周期价值，讲内容营销，因为他们也跟环信一样做的是小客户，可见对于小客户这一招中外通吃。而大客户不是这么玩的。
在美国做企业服务，底层有一批创业公司，天花板是做到几亿美元到几十亿美元市值，基本很难再往上突破了。这是因为大客户都被微软、甲骨文、Salesforce这样的公司牢牢掌握着，小企业根本没机会进入那个圈子。
某种程度上，中国也差不多，但也有很大不同。中国大型企业还没有强大的科技公司可以很好地服务于他们，这些年主要依赖于一些大型系统集成商，系统集成商的做法跟甲骨文等这些科技巨头又不一样，他们以项目运行的方式推进，在创新和积累上相对较弱。
以前中国的大型国企或私企也认可这种做法，但随着整体经济环境进入L型经济，增长放缓，企业追求利润的结果就是更加注重创新，尤其是服务创新，这两年刘俊彦明显地感觉到国内大型企业有一种创新急迫感，他意识到谁能服务中国500强企业，谁就会成为中国的甲骨文。
由于求稳，当年环信的竞争对手就没赶上这波新的机会。“如果我们到现在还只是在做最初的一个业务，我们也就成为了一家小老头公司。”刘俊彦平静地说。
2017年3月，环信完成1.03亿元的C轮融资，由经纬领投，银泰嘉禾跟投。
当然，考验仍然存在。SaaS是一种功能密集型的技术，最考验大规模研发团队的研发效率和管理能力。2016年新组建的智能机器人团队则是资本密集型，这个团队虽然人不多，但是一年投入却上千万元。
不同的技术、人才、资本结构，对于管理是一大考验。不过刘俊彦认为，既然创业就要全力以赴去做，“挖人要看眼光，选择很重要，路线很重要，信任也很重要，既然选择上了火箭飞船，就不要考虑是几等舱。”
作者 | 刘晓芳
微信编辑 | 李昊原
原文发表于《IT经理世界》，转载请注明
2
回复
0
回复
0
回复
0
回复
调用实时通信，发起视频聊天，呼叫方第一次呼叫会退出应用，必须点击应用才会出现呼叫界面，Android5.0以上不会存在这个问题，这是有版本要求吗？
回复塔笋 发起了问题 • 1 人关注 • 38 次浏览 • 2017-06-26 20:33
1
回复
急，聊天室收不到消息
木云落 回复了问题 • 2 人关注 • 69 次浏览 • 2017-06-26 19:29
1
回复
iOS 环信视频文件收到后报错 [Playback] ❗️Failed to queue any items.
木云落 回复了问题 • 2 人关注 • 33 次浏览 • 2017-06-26 19:13
2
回复
