瓜子应用业务是通过现场演讲组织的，并提供支持
1.介绍
在瓜子业务的重重防线下，许多环节，比如在线看车、去商店预约和达成交易，都发生在线下。瓜子即时通讯智能客户服务系统的目的是将这些离线活动转移到网上，跟踪离线行为并积累相关数据。该系统连接用户、客服、销售、人工智能机器人、商业背景等角色和应用，涵盖在线咨询、浏览、汽车预订、购物体验、售后服务、投诉等多个环节。，每个角色通过可直接操作的卡转移业务。
例如，当用户有买车的意图时，电话销售或人工智能机器人会及时将预定汽车的卡推给用户，用户只需要选择完成预定操作的时间。整个系统逻辑复杂，时效性和可靠性要求高，涉及即时消息、名片和各种实时统计。本讲座从数据架构层面解释了系统面临的挑战和解决方案。
冯玉:瓜子二手车高级技术专家，中国计算机联合会专业委员。2017年2月，他加入了瓜子二手车，主要负责研发瓜子即时通讯解决方案及相关系统。在瓜子期间，主持自主开发的信息系统，支持瓜子的内部效果工具，满足瓜子2万多名员工的移动办公需求；作为项目经理，他负责瓜子网上服务项目，该项目对瓜子二手车交易模式和流程产生了深远的影响。
3.文本概述
今天分享的主题是“瓜子即时消息智能客户服务数据架构设计”，类似于旺旺。
简要谈谈分享的一些内容:
第一部分:项目背景，项目背景需要谈一谈，这有助于大家理解；
第二部分是系统架构。为什么我们要简单地谈论系统架构？因为不谈论业务的体系结构是流氓式的，所以当我们谈论存储时，我们必须知道系统正在发生什么；
第三部分:关注存储。在这一部分，我们将分享我们的实践经验和进化过程，以及更多关于一些坑，以及如何解决它们。
4.项目背景
熟悉的人都知道，瓜子二手车没有中间商来赚取差价，但实际上瓜子不得不在中间做很多事情。
由现场讲座组织，支持PPT)_ timg.jpeg。
首先，二手车非常难。这不是标准产品。我们必须收集汽车，这些汽车在社会上收集，并通过网站收集。你必须检查汽车。我们想把它放在我们的网站上，一些汽车将从我们的网站上接收，一些汽车可能停在用户家楼下。如果用户来买车，在网上点击后，你可以下单看车，我们的销售人员会跟着你去看车，选择试驾，还有一系列的复检等。有很多事情。
根据现场演讲组织，支持PPT)_1.png
现在我们在瓜子方面做得不够好。为什么不呢？我们从瓜子里面看这件事。离线时有很多行为发生，我们很难防止它们造成很多问题。例如，如果你飞一张机票，其中一些将与其他企业挂钩，而这辆车将不会在平台上出售。这些问题很难解决。
第二是销售人员对用户做了什么。他可能会骂那些用户什么的。以后很难检查企业发现的投诉。然后我们项目的一个重要问题是解决一个在线问题，也就是将这些离线行为转移到在线，并且我们在即时通讯过程中使用通信来转移一些服务，从而巩固整个在线业务。
第三个是电子商务。我更喜欢用京东。我认为他的物流和客户服务非常好。瓜子也想被做成电子商务。另一个将降低成本，提高效率。如果你现在使用瓜子，你会发现当你在网上浏览时，你会被电话销售人员叫去。这很烦人，用户的体验也很糟糕。另一个对瓜子来说也很贵。我们也增加了很多电话营销。
根据现场演讲组织，支持PPT)_2.jpg
如前所述，它非常复杂。整个系统有许多角色串联，包括用户，销售，电力销售，评估师，人工智能和机器人。作为一个系统，我们应该善于抽象。我们首先有一个基于通信的即时通讯系统。其次，我们希望将通信系统集成到业务中，或者将这些业务转移到通信系统中。核心是这样的。
根据现场演讲组织，支持PPT)_3.png
这是几张照片的截屏。让我们看看第一张图片。我们在顶部有一辆车，在底部有一个约会。事实上，用户可以直接在聊天界面预约。这就是我所说的不同于一般的客户服务。它可以被称为购物指南或营销，直接通过这种方式。因为瓜子的客户成本很高，每个访问瓜子的用户都想及时与他沟通。这个数字有助于大家理解。
5.系统结构
根据现场演讲组织，支持PPT)_4.jpg
整个系统不是一个单一的系统，它结合了一些服务，我们可以把它分成几个层次。顶部是一端，在那一端，有瓜子应用程序，当然，也有毛豆。现在有好几家瓜子公司，另外，一些员工也在使用它们，比如销售、客户服务、售后服务和财务。我们可能都是一些应用或桌面系统，这是我们的客户。
第二个是路由层，我们需要通过这些服务。为了在这个系统中及时交付这些服务，刚才所谓的交付前面有一个模式。例如，如果你想要一辆车，客服会给你一张汽车卡，或者电话营销会给你一张汽车卡，你可以直接选择预约时间。这是送货服务。再往下是一些业务层，也就是说，有很多业务涉及到瓜子，而在底层是一个仓库。这一次，我们将主要从存储层的角度讨论整个系统，重点讨论存储层如何支持路由层。
6.存储架构
存储这篇文章将讨论几个要点，包括:
1)分割数据库；
2)如何保存消息，消息中会提到组的模型，大规模的组比较麻烦；
3)有一些存储逻辑以及业务如何在其上运行；
4)最后，对这些设备进行统计分析、实时计算。
6.1数据库拆分
根据现场演讲组织，支持PPT)_5.jpg
此图是当前数据库的地图。我们可以看到，数据库已经被很好地划分，如通信数据库，它有调度，卡和分析。
我想在这里介绍新术语“日程安排”。它是做什么的？也就是说，无论你在这个系统中点击一辆车还是一个人，在聊天的时候，用户看到的是一个瓜子客服，而在瓜子的后面，实际上有一个很大的瓜子客服团队在支持你，所以毕竟有一些策略可以和哪个客服聊天。
我们认为这种分裂实际上是合乎逻辑的，但实际上根本不是。让我给你举个例子。2015年，京东有一个股份，刘和分享，说有一个二手车公司一年或一个月。我忘了，卖出两辆车后，估值达到了2亿美元。真不敢相信。
我不同意这个例子，因为我的演讲没有错。当然，我相信他不是指瓜子，因为在第一轮的瓜子中有不止这个数。我想说的是，起初，企业规模很小，业务量也很小，所以我们根本没有这样的数据库结构。就像沈先生说的，实际上，它只是一个没有即时消息和时间表的数据库。这些卡片可能是销售汽车的数据库。
大约两年前，我在去年二月进入了瓜子行业。当时，瓜子的业务量很小。我不知道细节。这是一个数据库，一个非常好的数据库。因为许多人说他们想在他们来的时候拆除数据库，数据库的优点是它可以快速地写业务，十几个人可以快速地建立系统。
事实上，我们经历了一个过程，当我们把库分成这么多的时候。起初，只有一个即时消息库。后来，随着时间的推移，我们添加了一个库。后来，当有任何卡片时，分析必须逐渐扩展。
事实上，这个图书馆有一定的成本。如果你不能很好的分割它，你会做很多界面。例如，如果你检查关联，你会发现不是我的团队的库必须做各种各样的接口，导致分布式事物的一致性。因此，数据库拆分，尤其是垂直拆分，实际上意味着在不同的阶段，您可以选择不同的拆分方法。未来，随着系统的扩展，瓜子业务将会扩展该系统，将会拆分更多的数据库，但更多的拆分将会给您的运维监控团队带来一些成本和挑战。我们现在把它分解成这样一个图书馆，每个图书馆都履行自己的职责。
由现场演讲组织，支持PPT)_6.png
(原图来源于《现代即时通讯系统中聊天信息同步和存储方案的讨论》)
6.2如何保存消息
让我们关注下面的新闻。我们如何保存这一块？
让我们看看左边的图片。左边的图片通常很容易理解。如何保存它？
桌面系统过去常常这样做:例如，如果甲想给乙发信息，他怎么能发呢？他说，“甲客户，甲客户，我发一条信息，如果乙在线，我会直接发信息给他，他会给我一个确认，这个过程会在它被存储的时候完成。”。
实际上，我不需要在我的服务中存储这条消息。如果A发送了一个C，而这个C不在线，该怎么办？
我们也有策略:甲把这条消息发送给丙。如果丙不确认我收到这条消息，我会在下面的第二步保存它，我会在一个离线数据库里等你。当C上线时，你将把这条消息拉回来，这个过程就完成了。我将发送此消息，因此此时的存储非常简单，所以我只需将某人的消息保存在脱机数据库中。
然而，这种模式存在许多问题。当它被实际使用时，许多产品现在都是手机。网络起初是不稳定的，并且长期处于C状态。如果监视其状态，存储性能将非常差。
由现场演讲组织，支持PPT)_7.png
(原图来源于《现代即时通讯系统中聊天信息同步和存储方案的讨论》)
有许多第二终端:桌面终端，手机终端，应用终端和掌上终端，还有几个终端。如果它们都使用这种模式，实际上很难判断和查看每一端的传输数据。
我们改变了一种方式:第一步，当消息到来时，我们将把消息保存到存储库中，只要你发送消息，我就会为你保存它；步骤2，同时，我将把它保存到一个同步存储库中。
这两个库需要解释一下。存储库和同步库分别做什么？
知识库很容易理解。您可以随时从存储库中恢复您的消息，并将其读回。例如，如果你换了手机，你可以把信息拉回来。
这个同步库是什么意思？同步库意味着您没有更换手机或重新安装系统，也就是说，您可能会离线一段时间。离线后，我会说，例如，我假设一个消息序列将从1到100发送给你，而A将从1到100发送给C。结果，当C从70号那里得到消息时，他已经离线了，所以他没有在线。这样，当C终端上线后，第四步就是把70号消息发送到服务器，说我什么时候有70号消息同步库，然后把70号到100号的消息发送到C..这样，消息就可以传递到这个目的。这两个概念有点模糊，但没关系。稍后我会详细介绍它们。
也就是说，我们将保存一个消息同步库和一个存储库。这实际上是一个消息同步库，是一个模型。我的下一篇PPT应该谈谈如何保存它。
如果我们把它理解为一封邮件，你就能很好地理解它。我们的邮件有一个收件箱，同步库就像一个收件箱。不管是谁给你发的邮件，不管是批量发送还是寄出，我都会给你一份，并把一份放入收件箱。a把这封邮件放在邮件里，你必须把它从另一封里取出来。无论你是用手机还是用苹果笔记本或windows笔记本，你都必须收到这封邮件。什么是接收过程？例如，刚才谈到第一个苹果系统笔记本时，B1说我以前收到过前两个B光标，它在本地有最大的消息，说我在2号消息，我收到了。然后他把2号信息发给服务器，服务器说可以，后面的2号到20号信息可以被拿走。通过这种方式，可以保证该消息将被发送到客户端而不会丢失。
B2说我实际上在我的上一封邮件中收到了10封信，所以我在11: 00开始收到它们，B3说我只收到了一封信，所以我刚开始收到第二封邮件，这解决了问题并发送了消息。这里有几个问题。我们的同步过程理论上是可以的，但是有几个问题。第一种是扩散写和扩散读，这与存储有关。扩散写作和扩散阅读有很多讨论。
例如:它是在哪里产生的？例如，如果我一个人说话，我们两个聊天没有问题，我一定会把所有的消息都写给你。但事实上，大多数时候我们在一个小组里聊天，卖给我们，我们的评估者或机器人，他们都在里面聊天，用户也在里面聊天。我是为每个人写一份这个新闻，还是为整个谈话，也就是这个小组写一份？我只写并保存了一份，你们都读了。一条对话信息，或者你手里的收件箱，让我先总结一下。我们在消息的同步库中使用扩散写，并且在它后面有一个存储库。我们在存储库中使用扩散阅读。在同步库中，我们每个人都写一份副本，这非常便于阅读。在存储时，由于我们的存储速度较慢，我们只写了一段数据，并且在这个会话中只有一条消息。
第二点是，事实上，在同步的过程中，我们遇到了一些问题，我们需要考虑很多策略。这只是一条信息。有时不同的终端有不同的同步策略。例如，在某些情况下，我们要求每个终端接收该消息，即我们的通知，并且每个终端必须发送公司发送的优惠券。在某些情况下，他想说您的手机已经关闭，所以如果您打开桌面，我们将不再向您发送此消息。根据刚才的同步模型，每个有困难的终端都可以搜索这个消息，所以我们准备了三个这样的存储号码。
例如，在这个图中的B1B2B3，我们也有当前消息的最大消息数。第三个号码是你在里面搜索的所有信息的首页，它说它更像B2。通过这三个位置的组合，我们可以确定您接收消息或策略的位置。这就是这个模型。我们储存什么？我们使用Redis集群，我们使用SortedSet结构。
我特别提出来，因为我们实际上踩到了一个坑，所以我想保存这个信息，我们都需要知道这个结构的效率。我们检查了排序集的效率，说它是一个ln，所以在同步库中，如果每个用户只保存一部分消息，它的性能是非常高的。这个结构本质上是一个跳转表。跳转表结构实际上非常复杂。我认为在这次会议上很难解释清楚。最后，放两张图片，这是一本书。
我们知道这些结构，如二叉树或一些红黑树，有很好的索引策略和类似的跳转表。就像我们说一本书有1000页，我想翻到856页，这是什么意思？事实上，我们有办法去前面找到索引来定位某个东西，我可能会翻到800页，一步一步地修改它。本质上，跳台结构更像是翻一本书。我认为它正在变成一个大页面，首先变成800页，然后变成850页，然后逐渐变成860页。
让我们分享一下在这篇文章中我们遇到了什么问题！我们分类设置集合来存储和存储消息，并且我们使用了一个想法来存储消息以实现全局一致性。在这个算法中，我们的消息是一个长整数，也就是一个工作卡。我先谈谈这件事。我先来谈谈下面的精度损失问题。我们的信息是一个长整数。在这个场景中，总共有64位，所以雪花算法前面的第一位没有被使用，但是它实际上代表了一个正整数，这是有意义的。用41来表示一个时间间隔，其中生成的一些ID表示大约670年或340年，无论如何这肯定足够了。
中间的十位数是一个工作的机器号，可以支持1024台机器。现阶段我们不能用这么多机器。最后12位数字是一毫秒内的一个序列号，因此它构成了我们消息的标识。因此，消息是一个长字符串，并计算一个18位整数。
在把它放入分类后，我们后来发现了一些问题，发现时间和新闻很接近，我们无法区分它的顺序。深入挖掘后，我们发现SortedSet的十个单词实际上是双重类型的。下图描述的是双精度类型，其精度仅为52位。上面的长整型精度为63位，这里有11位的间隙。因此，在时间非常接近的消息中，它的准确性会丢失，当我们检索和提取时，这些序列会出错。
因此，我们采取了一种策略，也可以借鉴。根据我们当时的负载和机器数量，这最终保证了我们很难满足精度损失的问题，并减少了精度的主动转换。这个案例表明，当我们选择存储时，数据类型非常重要，因此您必须根据您的业务类型来看待它。
我们在这里同步时仍然遇到一些问题，也就是说，这个问题出现在我们内部的一个工具中。我们有很多群，有很多人，因为我们的信息就像一个收件箱，它的大小是有限的。一些大团体疯狂地刷信息。这样，该组中可能有数十万条消息。由于我们的收件箱容量有限，我们将删除早期的邮件，从而导致一些重要的邮件丢失。
第二个问题是仍然有一些网络终端，我们的网络终端，实际上，本地缓存很难使用，也就是说，我们的用户打开它后有多少未读的消息，我们只能计算有多少未读的消息我们先拉回来，有多少新的消息我们拉。这实际上是对我们的挑战，非常不友好。
6.3消息的插入存储
接下来，让我们谈谈存储。我们储存的信息将被储存在图书馆里。我们如何存储信息？
正如我们刚才提到的，它是根据你看到的每个人在每次对话中与你聊天的维度来存储的。我们还采用了划分数据库的策略，这相对简单。
这是一个例子:事实上，有不止一个库。我们将他的消息绘画的一个标识除以4，并取其模块来确定它被放入哪个库。刚才提到，我们的许多身份证是由雪花算法生成的，我们有办法防止它的不均匀存在。看看。这是一个防止其标识不均匀分布的方案。我们看到末尾有一个12位的序列号。如果你不干预，他每次都从零开始。事实上，当您的并发性相对较小时，您会发现所有的零都在后面，最后几个和您一样。如果它们都是零，你使用一个固定的模块化算法，他肯定是不均衡的。
例如，您的数据库是不够的，当您想要扩展它时，您会发现它非常困难。你不知道以前的数据，但你只能输出所有以前的数据，这简直是一场灾难。因此，我们需要人为干预。我们只是采用模块化的方式对子数据库进行特殊处理，加上一些子数据库行为。在这种情况下，我们使用了一个身份生成时间，并给他一个最后八位数的掩码。他在128个数据库里。
让我们来谈谈如何扩大产能:就在之前，业务量刚开始时很小，但几天前，瓜子每天卖10000辆车，所以现在我们将逐步增加这个数量。当售出10，000辆汽车时，用户数量非常大。我们如何扩大产能？这是扩展的基本方法。首先，我们有几个数据库，比如db0123。让我们看看这个图的左边，它是msg:chatid=100和msg:chatid=104。过去，当chatid被四除时，两个数据，100和104，在这个数据库中是重复的。
当我们分开图书馆时，我们应该做什么？在第一步中，我们同时把一个像db0123这样的库放到市场上，所以我想同步主和从。总之，我们正在处理db4567，db1和db5的数据与db0和db4的数据相同。我们改变了把图书馆分成八个来寻找剩余部分的策略，然后会发生什么呢？
我们发现，根据新的库拆分策略，chatid104仍在db0中，之后chatid100将转到db4，这意味着我们将直接从4个库更改为8个库。库拆分规则上线后，我们将删除数据库管理员不属于该库的其他数据，并对该库进行扩展，这样业务就可以继续运行，但这能解决问题吗？
事实上，这并不简单，因为我们数据库前面的数据库是MySQL。为了安全起见，他可能必须扩展数据库。数据库越来越多，所以他退出了数据库管理员的操作和维护，说你有越来越多的数据库。我如何维护它们？我受不了。
因此，另一种是这种关系数据库，它可以支持非常丰富的逻辑，例如具有许多事务相关性查询的事务。然而，事实上，在应用具有最大数量消息的数据量时，我们不需要如此复杂。这很简单。我要么根据消息标识查找消息，要么根据消息检索该范围内的消息。我真的不需要一些复杂的逻辑。因此，用于存储的关系数据库不是特别合适，所以我们将
首先，我们发现时间序列数据库是一个OpenTSDB，它的应用场景非常类似于这个业务。OpenTSDB是用Hbase在内部实现的，我们认为Hbase非常好。我们为什么选择Hbase？因为团队维护，这是非常现实的。选择Hbase后，使用过Hbase的学生会知道，除了切片，最重要的是设计Rowkey设计，它需要与业务相结合，设计得非常精致。我们的Rowkey的结果是一个会话聊天标识，它可以分散区域，msgid可以有序地用于范围检索。
如果我们用这个来咨询你，你会经常有一个场景。我打开我看到的最新新闻，我开始下载旧的新闻。这个结构出现后，我们将检索您的最新消息。当你滑下去时，我们将继续查看后面的新闻。这很快。如果当地没有什么，你可以安装一个新的。您可以直接在Hbase中查询最新的Rowkey，您会找到您的。
另一点是区域，就像子库一样，Hbase做得很好，它可以帮助你维护这个片段，但是我们不建议这样做来维护这个片段。当你有这样的消息时，它的存储容量非常小，默认情况下它很快会给你一个区域，但是这样的读写瓶颈会到来，所以我们需要提前规划我们子库的区域。
以下是一些具有一些特殊特征的群体。在我们的二手车APP中，这个大规模的团队相对较小，但我想分享的是，这个团队在我们内部沟通中遇到的一些问题也被提出来了，所以让我们与大家分享一下。
第一个是刚才提到的存储减少。这是以下存储库。例如，有许多团体，可能有2000多人。如果我发信息，我会保存2000份，这是一个灾难，所以我们只能保存一份。因此，在我们看了左边的蓝色之后，我们只保存了一份副本，它表明了消息的标识以及这是哪个会话或组。
因为保存了一份，第二个问题就来了:如果人们今天加入了这个团体，昨天加入这个团体的人们实际上看到了不同的新闻。
正常的生意是这样的。有时您可以看到最近实现了多少逻辑，也就是说，我们正在向它扩展一个数据库表。该表位于关系数据库中，记录了该组的编号、此人的身份以及他加入该组的时间。我们可以通过函数来计算。因此，消息标识策略非常重要。我们已经过了团体加时赛。因为它是时间的函数，所以我们可以用这个组添加时间来建立映射关系。通过这种方式，我可以大致定位他可以通过添加时间组从哪个消息中检索。如果你需要制定策略，你也可以说你想做多少就做多少。第三，还有一个对话顺序的问题。在这个对话场景中，我们可以看到会有很多对话，所以这是一个战略选择。
第一种方法:你可以为每个人创造一个对话。每次他有消息，你可以更新他的最后一次。这个过程可以满足对话的顺序，但事实上，我们能做到吗？我不认为我们能做到这一点，因为有时有很多信息，有时有很多用户，所以我们发送一条信息。有1000个人想更新他们的状态。不管你用多少，他们都应付不了。因此，我们也在缓存对话的最后一条消息。当用户想要拉他的对话列表或更新他的对话列表时，服务器会给他一个预算并返回给他。当我们使用它时，它通常可以在客户端本地接收消息。如果你在线，他知道如何调整这些数据。当会话离线并再次打开时，拉会话的行为此时需要更新。如果这个频率相对较低，我们的存储模型就会出来。因此，当许多其他服务发生时，我们跟踪她的状态，并且我们可以在对该会话进行排序时设置该过程，例如，当我们读取它时。
后者已被阅读和未读，所以这一点并不详细，也没有特点。我们知道，缓存中为每条消息构建了一个存储结构，说明哪些人读过这条消息，哪些人没有读过，并在相对较短的时间内消除它。消息被撤回。一个小同学以前做过这个。这个消息怎么能撤回？在关系数据库中，需要撤回该消息。我在表格中标出这条信息。此消息已撤回。这种做法有什么问题吗？一点问题都没有。
在那之后，他又提出了另一个要求，说我只是想看到尚未撤销的消息。毕业后不久，这位同学调整了一下，并想建立一个指标。他建立了索引，这样他就可以提取数据。结果，数据库转交给警方一段时间。这没用。怎么回事？因为撤回消息与正常未撤回消息的比率是一个具有非常小的间隔的不平衡索引，所以它是没有意义的，并且会消耗写消息的性能。因此，有两种方法可以撤回消息。第一种方法是从这个消息库中删除它们，并将它们移动到一个撤回的消息表中，这是显而易见的。另一种方法是我们也标记，但不索引，我不支持您过滤和接受，但我会不加选择地将它提取出来，并在存储的逻辑层上过滤掉。
如下所述，我们讨论的存储结构不仅仅是像数据库这样简单的概念，还包括数据库和业务之间的一些协议、规范或复杂性降低，因为让业务直接处理不好，所以我们有存储逻辑，所以逻辑层做一些基本的逻辑。
让我在这里与你分享:瓜子塔APP的地位不够高。当我第一次使用它的时候，我必须在一点钟登录，所以我们必须做一些匿名策略。我们希望你能在匿名状态下建立联系。如果你认为我们可以继续交谈、出售汽车或购买汽车，那么匿名将会给我们的业务带来挑战。当我们匿名时，我们可以给他一个身份，他认为可以聊天。它登录了。登录后，当他的真实姓名被创建时，他的真实姓名可能是新创建的，或者他可能之前已经注册过，但是因为他忘记了它，或者它在很长一段时间后过期了，此时他在这个业务流程中，他有两个身份证。如果他一直做两个身份证，对他身后的销售人员来说实际上是非常沮丧的。他说我们开始和我说话，但是过了一会儿，他变成了一个人。因此，我们在这个消息级别进行了合并。我们没说你的真名，所以我们转移了你的数据。根据这个真实的名字，匿名有一个时间序列，不管是否有一个真实的名字，我们没有这样做，我们仍然有两个，但我们把它拉在一个存储中间的水平。当需要合并时，我们在存储逻辑中把它交给了他。
但是匿名实名制远非简单，它只是一种延伸。事实上，你信息中的匿名性很好，但是你的企业很难匿名到真实姓名。此外，我们经常会遇到这个问题。机器人给了他一样匿名的东西。后来，他登录了。在他打开并把它拉回来后，信息仍然在他身边，他成了一个真实的名字。当他经营的时候，企业实际上更难匿名。如果有人这样想，他们应该提前思考，更多的商业层面的理论是可用的。
这是消息的最后一部分。事实上，会有一些问题。事实上，消息同步是一件非常复杂的事情，我们以后做得越多，它就越复杂。有些人会怎么样？例如，我在A手机上收到了几条消息，在B手机上收到了几条消息，过了一会儿我在A手机上收到了几条消息。
看看刚才的模型，中间会有很多错误，就像客户端右边的图片，他没有收到345的消息，但是服务器实际上有所有的消息。此时，我们制定了一些策略，我们严格地对每条消息进行编号，消息索引:1，2，3，并严格地对每条消息进行编号。如果是这样的话，当客户知道的时候，他就会知道我漏掉了三个数字345，对吗？我可以去服务器说，我缺345条信息，所以请帮我查一下。
有那么简单吗？客户可能认为这很容易，但当涉及到服务器时，情况并非如此。345是你自己编的一个数字，我们的信息说雪花以前是一个唯一的数字，所以你不能知道你和345在一起的是哪个信息，所以我应该用哪个信息来建立这样一个索引，或者它应该是一个数字到消息标识索引？
是的，但是存储量很大，所以我们该怎么办？
我们在逻辑层做一些事情。每次服务器从客户端返回一条消息，我们就把这条消息做成一个链表结构。当你拉它的时候，因为它有很多反向信息，对吗？当我调出第二条信息时，我说，我会告诉你这个。你的下一条信息是msg7。你是否拉它无关紧要，或者你可以一段一段地拉它。当你拉ms6时，我告诉你你的消息ms5，我的客户说这个消息5不见了。通过这种方式，客户端可以通过该消息标识从服务器检索消息。因为它是一个消息标识，所以无论我们是否正常，或者我们的关系数据库是基于索引的，它都是容易做的和现成的，并且不需要维护其他索引关系。所以这也是一个战略点。我们可以解决这个问题。
然而，仍然存在问题。有时候信息太多了。如果您从刚才提到的同步库中收集这些消息，这个过程实际上非常慢，尤其是对于深度用户。
有一种方法:你可以压缩这条信息，并把它发送到过去，然后简单地传递下去。但事实上，它仍然不好。客户端需要渲染，计算量很慢。这就是刚才提到的扩散阅读和扩散写作的问题。最早有一个。因此，稍后更好的说法是，同步库中没有要同步的特定消息。您可以在用户已经更改的地方进行会话。对于这样的会话，有多少数据没有收到，有多少未读的数据被记录下来。这样，客户端可以在本地提取数据。当您看到有多少未读会话后，当您单击时，您可以在这个存储库中以相反的方向通过它来获取您的消息。此外，我们刚刚提到了填充中间空间的策略和填充列表的策略。这种经历非常好。
所以我们解决了我们的项目，也解决了新闻问题。稍后，让我们看看新闻并解决它。我们必须推广这个项目。我们必须着陆并且需要做生意，因为仅仅发送信息是没有意义的。对于观众来说，我们是在做生意。我们做生意就是给我们打电话。名片，我们在原图中看到的东西，过去可以直接操作，我们也应该申请专利。当时，我们核实没有人这样做，但因为没有人这样做，事实上，我们正在实施过程中。
在这个图的右边有一个卡代理，右边的绿卡代理是我们为这个业务设置的一个特殊的东西。我们在推广时遇到了很多问题。我们业务的所有原始业务部门都制作了现成的界面。自从你把它移到即时通讯互动中，有几种方法:首先，你可以为我改变它，这是非常困难的。一些企业说他不愿意。我们已经设计了由这样一个代理产生的卡的所有响应导频，首先调用我们的一个代理模块，然后代理模块适应您的原始业务逻辑。这样，代理模块知道用户的操作行为是什么，是否成功，是否成功，然后通过调度通过他们的渠道通知相关业务的所有方。这是一种策略。
同时，它应该是高度可靠的。例如，如果我们预约看车，这相当于下班，这相当于这个非常重要的业务。你不能这么做。链条太长，风险太高。我们宁愿添加一些东西。这是左边的逻辑。这项商业服务愿意说我会自己改变它。我必须自己控制可控性。我不能说我的生意会因为沟通问题而停止。也就是说，他改变了一些逻辑来触发调度。这是整个推广过程中最重要的策略，因为它不仅是一个技术问题，也是一个组织结构问题，所以实际上是在探索。
简单提一下日程安排问题，因为这不是重点，你怎么知道哪个客户会为你服务？我们提出了场景的概念，也就是说，每次你从不同的入口进入对话界面，这些入口都处于一种状态。例如，入口A，入口B，如果你想要一辆车或者便宜货什么的，我们会先向调度员登记这个场景，说我会到这里来，调度员会有一些大数据来支持它。如果你是你自己，你会从这个场景中出现，我们认为你可能在做什么。这样，他就回到了现场。当他再次与渠道建立关系时，带着这个场景，我们的调度员会知道把你推给谁，无论是销售还是机器人，这是我们解决投诉或解决任何销售的具体客户服务。
6.4分析和统计
接下来，让我们谈谈分析和统计。瓜子的规模已经相当大了。我们现在有超过1000个R&D团队，但是我们在大数据方面投资更多，但事实上，公司现在是数据驱动的。这个团队的力量仍然非常有限。它支持各种业务线。这是非常困难或非常繁忙的，所以我们有两个分析和统计。第一种是对T+1的离线分析，第二种是实时分析。
我们的项目对实时统计有很高的要求，如及时响应率，这就需要实时监控和报警。怎么做？从另一个角度来看，这是我们整个系统的架构。对于一些与我们相关的消息或一些与我们相关的业务安排，我们都采用了卡夫卡式的方式，即一些销售评估人员被派往客户服务部等，而这些他们业务线的逻辑，我们通过卡夫卡传递了一些更多的数据。我们想知道我们是否可以简单地通过借用卡夫卡来实现这项技术。事实上，我们可以。这个概念是一个流式数据库。我们最初的结构是图的左边部分。整个系统中间的信息已经传递了一个卡夫卡。
我们可以确保业务在它上面运行。其次，卡夫卡缓存了这段数据，我们可以对它进行流计算。我们的整体架构如上所示。
----------------------------------------------------------------------------------
哇谷im_im即时通讯_私有云_公有云-哇谷云科技官网-JM沟通
IM下载体验 - 哇谷IM-企业云办公IM即时聊天社交系统-JM 沟通下载
IM功能与价格 - 哇谷IM-提供即时通讯IM开发-APP搭建私有化-公有云-私有化云-海外云搭建
新闻动态 - 哇谷IM-即时通讯热门动态博客聊天JM沟通APP
关于哇谷-哇谷IM-提供企业即时通讯IM开发-语音通话-APP搭建私有化-公有云-私有化云-海外云搭建
联系我们 - 哇谷IM-即时通讯IM私有化搭建提供接口与SDK及哇谷云服务
公有云和私有云之间有什么区别？类似融云、环信云、网易云、哇谷云？