对用户的长关系链数据的处理系统和方法.pdf

《对用户的长关系链数据的处理系统和方法.pdf》由会员分享，可在线阅读，更多相关《对用户的长关系链数据的处理系统和方法.pdf（14页完整版）》请在专利查询网上搜索。

1、(10)申请公布号 CN 103838757 A (43)申请公布日 2014.06.04 CN 103838757 A (21)申请号 201210483647.5 (22)申请日 2012.11.26 G06F 17/30(2006.01) (71)申请人 腾讯科技 （深圳） 有限公司 地址 518044 广东省深圳市福田区振兴路赛 格科技园 2 栋东 403 室 (72)发明人 王辉 (74)专利代理机构 北京德琦知识产权代理有限 公司 11018 代理人 张晓峰 宋志强 (54) 发明名称 对用户的长关系链数据的处理系统和方法 (57) 摘要 本申请公开了一种对用户的长关系链数据的 处。

2、理系统和方法， 包括 ： 缓存模块响应前端对所 述用户的长关系链数据的操作请求， 将其中的修 改请求同步发送给后述的接收模块 ； 接收模块接 收来自所述缓存模块的修改请求， 将所述修改请 求同步保存到非内存存储设备的操作日志文件 中 ； 入库模块读取所述接收模块的操作日志文件 中的修改请求， 并按照读取的修改请求修改数据 库中的长关系链数据。 利用本发明， 可以以降低丢 失修改请求的几率， 降低数据库中的长关系链数 据的数据错误率。 (51)Int.Cl. 权利要求书 2 页 说明书 7 页 附图 4 页 (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书2页 说明书7页 。

3、附图4页 (10)申请公布号 CN 103838757 A CN 103838757 A 1/2 页 2 1. 一种对用户的长关系链数据的处理系统， 其特征在于， 包括 ： 缓存模块， 设置在内存中， 用于响应前端对所述用户的长关系链数据的操作请求， 将其 中的修改请求同步发送给后述的接收模块 ； 接收模块， 用于接收来自所述缓存模块的修改请求， 将所述修改请求同步保存到非内 存存储设备的操作日志文件中 ； 入库模块， 用于读取所述接收模块的操作日志文件中的修改请求， 并按照读取的修改 请求修改数据库中的长关系链数据。 2. 根据权利要求 1 所述的系统， 其特征在于， 该系统进一步包括 ： 。

4、划分用户模块， 用于 对用户人群进行单元划分， 将单元信息通知给所述缓存模块、 接收模块和入库模块 ； 所述缓存模块进一步用于 ： 区分发起所述修改请求的用户所属的单元， 将所述修改请 求及其单元信息同步发送给所述接收模块 ； 所述接收模块进一步用于 ： 为不同的单元分别对应建立至少一个操作日志文件， 将所 述修改请求同步保存到该修改请求对应单元的操作日志文件中 ； 所述入库模块进一步用于 ： 按照所述单元信息为不同的单元对应建立不同的数据库， 并在修改数据库时， 按照读取的修改请求修改该修改请求对应单元的数据库中的长关系链 数据。 3. 根据权利要求 2 所述的系统， 其特征在于， 所述接收。

5、模块进一步用于 ： 针对每一单元， 在内存中记录同步保存所述修改请求的同 步进度信息， 并将所述同步进度信息反馈给所述缓存模块 ； 在本接收模块停机重启后， 针对 每一单元， 扫描该单元的操作日志文件， 根据该单元最新的操作日志文件恢复该单元的同 步进度信息， 并将该单元的同步进度信息反馈给所述缓存模块 ； 所述缓存模块进一步用于 ： 根据所述接收模块反馈的各个单元的进度信息同步发送对 应单元的、 该进度之后的修改请求给所述接收模块。 4. 根据权利要求 3 所述的系统， 其特征在于， 所述接收模块中具体包括同步进度记录 模块， 用于记录所述同步进度信息， 在每次操作操作日志文件同步保存一条修。

6、改请求完毕， 就把该操作日志对应单元的同步进度信息加 1。 5. 根据权利要求 2 所述的系统， 其特征在于， 所述入库模块进一步用于 ： 针对每一单元， 在内存中记录对该单元操作日志文件中的 修改请求的读取进度信息， 每读完一个操作日志文件则标记该文件已读 ； 在本入库模块停 机重启后， 针对每一单元， 扫描该单元的操作日志文件， 根据保存时间最久的未读操作日志 文件恢复该单元的读取进度信息， 按照该单元的读取进度信息接续读取该单元的操作日志 文件中的修改请求， 并按照读取的修改请求修改数据库中的长关系链数据。 6. 根据权利要求 5 所述的系统， 其特征在于， 所述入库模块中具体包括读取进。

7、度记录 模块， 用于记录所述读取进度信息， 每读取一单元的操作日志文件中的一条记录， 就把对应 单元的读取进度加 1。 7. 一种对用户的长关系链数据的处理方法， 其特征在于， 包括 ： 缓存模块响应前端对所述用户的长关系链数据的操作请求， 将其中的修改请求同步发 送给后述的接收模块 ； 接收模块接收来自所述缓存模块的修改请求， 将所述修改请求同步保存到非内存存储 权 利 要 求 书 CN 103838757 A 2 2/2 页 3 设备的操作日志文件中 ； 入库模块读取所述接收模块的操作日志文件中的修改请求， 并按照读取的修改请求修 改数据库中的长关系链数据。 8. 根据权利要求 7 所述的。

8、方法， 其特征在于， 该方法进一步包括 ： 对用户人群进行单元划分， 将单元信息通知给所述缓存模块、 接收模块和入库模块 ； 所述缓存模块进一步区分发起所述修改请求的用户所属的单元， 将所述修改请求及其 单元信息同步发送给所述接收模块 ； 所述接收模块进一步为不同的单元分别对应建立至少一个操作日志文件， 将所述修改 请求同步保存到该修改请求对应单元的操作日志文件中 ； 所述入库模块进一步按照所述单元信息为不同的单元对应建立不同的数据库， 并在修 改数据库时， 按照读取的修改请求修改该修改请求对应单元的数据库中的长关系链数据。 9. 根据权利要求 8 所述的方法， 其特征在于， 该方法进一步包括。

9、 ： 所述接收模块针对每一单元， 在内存中记录同步保存所述修改请求的同步进度信息， 并将所述同步进度信息反馈给所述缓存模块 ； 在本接收模块停机重启后， 针对每一单元， 扫 描该单元的操作日志文件， 根据该单元最新的操作日志文件恢复该单元的同步进度信息， 并将该单元的同步进度信息反馈给所述缓存模块 ； 所述缓存模块根据所述接收模块反馈的各个单元的进度信息同步发送对应单元的、 该 进度之后的修改请求给所述接收模块。 10. 根据权利要求 9 所述的方法， 其特征在于， 所述在内存中记录同步保存所述修改请 求的同步进度信息， 具体包括 ： 每次操作操作日志文件同步保存一条修改请求完毕后， 就把 该。

10、操作日志文件对应单元的同步进度信息加 1。 11. 根据权利要求 9 所述的方法， 其特征在于， 所述根据单元的最新的操作日志文件恢 复同步进度信息， 具体包括 ： 确定该单元的保存时间在该最新的操作日志文件之前的操作 日志文件数目m， 将该数目乘以一个操作日志文件的记录容量n， 将mn作为该单元的同步 进度信息。 12. 根据权利要求 8 所述的方法， 其特征在于， 该方法进一步包括 ： 所述入库模块针对每一单元， 在内存中记录对该单元操作日志文件中的修改请求的读 取进度信息， 每读完一个操作日志文件则标记该文件已读 ； 在本入库模块停机重启后， 针对 每一单元， 扫描该单元的操作日志文件，。

11、 根据保存时间最久的未读操作日志文件恢复该单 元的读取进度信息， 按照该单元的读取进度信息接续读取该单元的操作日志文件中的修改 请求， 并按照读取的修改请求修改数据库中的长关系链数据。 13. 根据权利要求 12 所述的方法， 其特征在于， 所述在内存中记录对该单元操作日志 文件中的修改请求的读取进度信息， 具体包括 ： 每读取一单元的操作日志文件中的一条记 录， 就把对应单元的读取进度加 1。 14. 根据权利要求 12 所述的方法， 其特征在于， 所述根据保存时间最久的未读操作日 志文件恢复单元的读取进度信息， 具体包括 ： 确定该单元的保存时间最久的未读操作日志 文件之前的操作日志文件数。

12、目M， 将该数目乘以一个操作日志文件的记录容量n， 将Mn作 为该单元的读取进度信息。 权 利 要 求 书 CN 103838757 A 3 1/7 页 4 对用户的长关系链数据的处理系统和方法 技术领域 0001 本申请涉及计算机和互联网数据处理技术领域， 尤其涉及一种对用户的长关系链 数据的处理系统和方法。 背景技术 0002 目前， 随着互联网技术的发展， 网络逐渐成为人们获取信息的重要来源， 特别是在 互联网进入 Web2.0 时代后， 用户既是网站内容的浏览者， 也是网站内容的制造者。用户参 与创造的内容被称为用户生成内容 （UGC， User Generated Content） 。

13、， 如用户发布的日志、 照片等， 在 Web2.0 时代， 由于 UGC 的大量涌现， 网络信息量呈几何级快速增长。 0003 目 前 最 活 跃 的 网 络 通 信 系 统 之 一 就 是 社 交 网 络 服 务 系 统 （SNS， Social NetworkService） 。SNS 简称为社交网络系统， 是旨在帮助人们建立社会性网络的互联网应 用服务系统。目前几乎所有的网站系统都在扩展其社交便利性， 为其增加 SNS 特性， 本文中 将所有具有 SNS 特性的网站系统称为社交网络系统， 例如 ： 网上社区系统、 博客系统、 微博 客系统 （简称微博） 等。 0004 在 SNS 中， 。

14、每个用户都是信息的发布者， 几乎时时刻刻都在生产出大量的 UGC。而 且每个用户都有其自身的关系链， 所述用户关系链主要包括在 SNS 中能和该用户进行互动 的用户群体， 用户关系链数据中包括这个群体中的每一个用户的标识、 属性等信息， 以及每 一个用户与主用户的关系。 其中， 有些用户的关系链中的用户数量巨大， 这种关系链在业界 被称为长关系链， 拥有长关系链的用户被称为长关系链用户。 0005 例如， 微博客 （MicroBlog） ， 简称微博， 是一个基于用户关系的信息分享、 传播以及 获取的 SNS 系统， 用户可以通过有线通信网络或无线通信网络、 以及各种客户端访问微博， 以指定数。

15、目的文字和 / 或其它多媒体信息更新信息， 并实现即时分享。在微博系统中， 每一 个用户都可以收听 （或关注） 其它用户， 即被该用户收听 （或关注） 的用户所发布的微博信息 （即 UGC） 可以及时地传输到该用户的微博中， 收听者就是被收听者的 “听众” （有些微博系统 中也叫 “粉丝” ， 本文中以听众为例进行说明） 。当然所有的用户也可以被其它用户收听 （或 关注） 。当某一用户的听众的数量超过一定数目之后， 则该用户就变成了长关系链用户， 例 如微博中的一些明星用户， 其听众的数量往往有几百万甚至上千万。 0006 在生产 UGC 的 SNS 中， 由于数据是用户产生的， 海量的用户催。

16、生出海量数据， 最终 带来更大量级的数据读写请求。特别是长关系链用户的数据处理， 由于其长关系链中包括 百万级甚至千万级数量的听众， 添加或删除一个听众也要对被收听用户的长关系链进行相 应的数据修改， 因此针对长关系链数据的请求的数量巨大， 触发频繁， 导致对相应的数据库 的操作量也巨大和频繁。因此对用户的长关系链数据需要特殊的处理。 0007 图1现有技术中的一种针对长关系链用户数据的处理系统。 参见图1， 该系统中主 要包括缓存 （cache） 模块和入库模块。所述数据库中保存了长关系链用户的全量长关系链 数据， 例如微博系统中是全量的听众列表， 而由于长关系链用户读取微博并不需要全量听 。

17、众列表， 并为了向前端极速的响应这类长关系链用户的对听众列表的读取请求， 因此将每 说 明 书 CN 103838757 A 4 2/7 页 5 一长关系链用户的一部分听众列表按更新时间保存在内存的缓存模块中， 该缓存模块用于 响应前端 （如客户端， 网页前端， 即用户操作端） 对所述长关系链用户的长关系链数据的操 作请求， 由于内存操作迅速， 因此可以极速响应长关系链用户对关系链数据的读取请求。 对 于写操作请求， 即需要对相应数据库进行入库修改的修改请求， 则需要将这些修改请求同 步给所述入库模块， 由入库模块根据这些修改请求修改数据库中的数据。 0008 但是上述现有技术具有如下缺点 ：。

18、 0009 由于缓存模块是纯内存操作， 入库模块是直接对底层数据库进行操作， 而操作数 据库和纯内存操作的速度不是一个数量级， 速度相差太悬殊。为了解决 Cache 模块和入库 模块速度的不一致， 缓存模块必须长时间保存对长关系链用户的操作日志， 直到入库模块 完成对数据库的操作才能释放操作日志占用的空间， 因此现有技术对用户的长关系链数据 的入库存储需要严重依赖缓存模块， 不但占用了缓存模块的大量内存空间， 而且一旦缓存 模块出现异常重启则会清空内存， 进而丢失大量的修改请求， 导致数据库中的长关系链数 据与前端操作严重不符， 数据错误率高。 发明内容 0010 有鉴于此， 本发明的主要目的。

19、在于提供一种对用户的长关系链数据的处理系统和 方法， 以降低丢失修改请求的几率， 降低数据库中的长关系链数据的数据错误率。 0011 本发明的技术方案是这样实现的 ： 0012 一种对用户的长关系链数据的处理系统， 包括 ： 0013 缓存模块， 设置在内存中， 用于响应前端对所述用户的长关系链数据的操作请求， 将其中的修改请求同步发送给后述的接收模块 ； 0014 接收模块， 用于接收来自所述缓存模块的修改请求， 将所述修改请求同步保存到 非内存存储设备的操作日志文件中 ； 0015 入库模块， 用于读取所述接收模块的操作日志文件中的修改请求， 并按照读取的 修改请求修改数据库中的长关系链数。

20、据。 0016 一种对用户的长关系链数据的处理方法， 包括 ： 0017 缓存模块响应前端对所述用户的长关系链数据的操作请求， 将其中的修改请求同 步发送给后述的接收模块 ； 0018 接收模块接收来自所述缓存模块的修改请求， 将所述修改请求同步保存到非内存 存储设备的操作日志文件中 ； 0019 入库模块读取所述接收模块的操作日志文件中的修改请求， 并按照读取的修改请 求修改数据库中的长关系链数据。 0020 与现有技术相比， 本发明引入了接收模块， 缓存模块将前端的对用户长关系链数 据的修改请求同步给该接收模块， 由该接收模块将所述修改请求同步保存在非内存存储设 备的操作日志文件中， 而入。

21、库模块不是从缓存模块获取前端的修改请求， 而是通过读取所 述接收模块的操作日志文件来获取修改请求， 并根据修改请求修改数据库中的长关系链数 据。因此， 本发明将所述缓存模块和入库模块成功解耦， 通过增加一个接收模块， 来协调快 速的修改请求和慢速的数据库操作， 从缓存模块同步修改请求到接收模块的同步速度较 快， 而接收模块中的操作日志文件又可以长时间保存供入库模块读取， 因此缓存模块不必 说 明 书 CN 103838757 A 5 3/7 页 6 长时间保存对长关系链用户的操作日志， 降低缓存模块对内存空间的占用， 也降低了由于 缓存模块异常重启导致丢失修改请求的几率， 进而保证数据库中的长。

22、关系链数据与前端操 作的符合程度， 降低了数据库中的长关系链数据的数据错误率。 附图说明 0021 图 1 现有技术中的一种针对用户的长关系链数据的处理系统 ； 0022 图 2 为本发明所述对用户的长关系链数据的处理系统的一种组成示意图 ； 0023 图 3 为本发明所述对用户的长关系链数据的处理方法的一种流程图 ； 0024 图 4 为本发明所述具体实施例的一种流程图 ； 0025 图5为图4所述实施例中当接收模块因为运维动作、 机器重启、 模块异常而重启时 的流程图 ； 0026 图6为图4所述实施例中当入库模块因为运维动作、 机器重启、 模块异常而重启时 的流程图。 具体实施方式 00。

23、27 下面结合附图及具体实施例对本发明再作进一步详细的说明 0028 图 2 为本发明所述对用户的长关系链数据的处理系统的一种组成示意图。参见图 2， 该处理系统包括缓存 （cache） 模块 201、 接收模块 202、 以及入库模块 203。 0029 所述缓存模块 201 设置在内存中， 在该缓存模块 201 中缓存了长关系链用户的最 新更新的一部分长关系链数据， 用于响应前端 （如客户端， 网页前端， 即用户操作端） 对所述 用户的长关系链数据的操作请求， 针对其中大部分的读取请求， 可以直接从该缓存模块 201 中读取并将读取结果返回给前端， 从而实现长关系链用户的关系链数据的极速读。

24、取响应。 而对于前端对所述用户的长关系链数据的修改请求， 例如微博系统中的添加听众请求、 删 除听众请求、 修改听众请求， 则将这些修改请求同步发送给所述接收模块 202。 0030 所述接收模块 202 用于接收来自所述缓存模块 201 的修改请求， 将所述修改请求 作为日志记录同步保存到非内存存储设备的操作日志文件 （Binlog） 中， 即该操作日志文件 不是保存在内存中， 而是保存在诸如硬盘等存储设备中。由于对长关系链用户的长关系链 数据的修改请求规模巨大， 因此可以在一个操作日志文件写满后， 增加新的操作日志文件 来保存所述修改请求。写操作日志文件的速度要比操作数据库的速度快很多， 。

25、与读取内存 的速度相差不多， 因此缓存模块 201 中接收到的修改请求可以快速地同步给接收模块 203。 0031 所述入库模块 203 用于操作数据库 （DB） ， 具体用于读取所述接收模块 202 的操作 日志文件中的一条条的日志记录即修改请求， 并按照读取的修改请求修改数据库中的长关 系链数据。例如如果是向该长关系链用户添加听众的请求， 则在数据库中的该用户的长关 系链数据中添加所述听众。 0032 由于操作底层数据库的操作与内存操作的速度相差很多， 因此入库模块 203 需要 较长时间地读取所述接收模块 202 的操作日志文件， 而所述操作日志文件保存在非内存的 存储设备中， 即使由于。

26、故障、 维修等原因停机， 这些操作日志文件也不会丢失， 降低了修改 请求的丢失几率， 进而保证数据库中的长关系链数据与前端操作的符合程度， 降低了数据 库中的长关系链数据的数据错误率。同时， 所述内存中的缓存模块 201 能够快速地将对用 说 明 书 CN 103838757 A 6 4/7 页 7 户的长关系链数据的修改请求同步给所述接收模块 202， 因此缓存模块 201 不必长时间保 存对长关系链用户的操作日志， 降低缓存模块 202 对内存空间的占用。 0033 另外， 图 1 所示的现有技术中还存在模块扩展难的缺陷， 即现有技术中的入库模 块只会把长关系链用户的长关系链数据保存到一个。

27、数据库里。当系统的数据量增大后， 需 要进行系统扩容， 在扩容时必须重新创建一套入库模块和容量更大的数据库， 然后将原有 数据库中的数据全部迁移到新的数据库中。 这种每扩展一次就要进行全量的数据迁移造成 了对系统设备运营维护的困难。 0034 作为一种改进， 在本发明的一种实施例中， 所述对用户的长关系链数据的处理系 统还进一步包括划分用户模块， 用于对用户人群进行单元划分， 将单元 （Unit） 信息通知给 所述缓存模块 201、 接收模块 202 和入库模块 203。所述对用户人群进行单元划分， 就是将 用户人群进行分组， 每一组称为一个单元， 这样方便扩展。 0035 在该实施例中， 所。

28、述缓存模块 201 进一步用于 ： 区分发起所述修改请求的用户所 属的单元， 将所述修改请求及其单元信息同步发送给所述接收模块。 0036 所述接收模块 202 进一步用于 ： 为不同的单元分别对应建立至少一个操作日志文 件， 如图 2 所示， 并将所述修改请求同步保存到该修改请求对应单元的操作日志文件中。对 于某一个单元， 可以在一个操作日志文件写满后， 增加新的操作日志文件来保存该单元对 应的修改请求。 0037 所述入库模块进一步用于 ： 按照所述单元信息为不同的单元对应建立不同的数据 库， 如图 2 所示， 并在修改数据库时， 按照读取的修改请求修改该修改请求对应单元的数据 库中的长关。

29、系链数据。 0038 本发明通过对用户群体进行单元划分， 形成了最小的处理单元， 在对用户的长关 系链数据的处理过程中， 接收模块 202 和入库模块 203 都是按照单元为单位处理修改请求 和存储入库的。当 SNS 系统中的用户总量攀升后， 可以将新增的用户划分到新的单元中， 在需要扩容接收模块 202 和入库模块 203 时， 可以新增处理设备 （如服务器） 放置新扩容的 接收模块和入库模块以及数据库， 只需要把要迁移的单元的操作日志文件复制到新增的接 收模块中， 并开启新增的接收模块和入库模块和数据库， 然后在所述缓存模块中添加新增 的接收模块的路由信息， 以使缓存模块可以将该新单元的修。

30、改请求同步发送给新的接收模 块。 如果要扩容数据库， 只需求停止入库模块的运行， 把原数据库数据复制到目的地或增加 新增单元对应的数据库， 修改入库模块中的新增数据库的路由信息， 然后开启入库模块即 可。 0039 本发明由于采用了分单元处理， 方便接收模块、 入库模块以及数据库的扩展扩容， 因此运营维护简单。 同时， 由于可以非常方便地扩展扩容相关设备， 因此可以对突发的数据 量暴增作出及时的设备扩展扩容处理， 从而保证整个 SNS 系统对前端数据请求的较快的响 应速度。 0040 这本发明的又一种实施例中， 所述接收模块 202 进一步用于 ： 针对每一单元， 在内 存中记录同步保存所述修。

31、改请求的同步进度信息， 并将所述同步进度信息反馈给所述缓存 模块 201 ； 在本接收模块停机重启后， 针对每一单元， 扫描该单元的操作日志文件， 根据该 单元最新的操作日志文件恢复该单元的同步进度信息， 并将该单元的同步进度信息反馈给 所述缓存模块。所述缓存模块 201 进一步用于 ： 根据所述接收模块反馈的各个单元的进度 说 明 书 CN 103838757 A 7 5/7 页 8 信息同步发送对应单元的、 该进度之后的修改请求给所述接收模块。 0041 例如， 接收模块返回的第 i 个单元的进度信息为第 1000 条， 则缓存模块收到该进 度反馈后再发送该第 i 个单元的第 1001 条。

32、修改请求及其后续的修改请求。因此可以进一 步保证接收模块由于故障、 运维动作等导致的停机重启后， 可以快速自动同步在所述接收 模块停机期间未同步成功的修改请求， 降低了运营维护的难度。 0042 具体的， 所述接收模块中具体包括同步进度记录模块， 用于记录所述同步进度信 息， 在每次操作操作日志文件同步保存一条修改请求完毕， 就把该操作日志对应单元的同 步进度信息加 1， 从而实现记录同步保存所述修改请求的同步进度信息。 0043 在又一种实施例中， 所述入库模块也可以进一步用于 ： 针对每一单元， 在内存中记 录对该单元操作日志文件中的修改请求的读取进度信息， 每读完一个操作日志文件则标记 。

33、该文件已读 ； 在本入库模块停机重启后， 针对每一单元， 扫描该单元的操作日志文件， 根据 保存时间最久的未读操作日志文件恢复该单元的读取进度信息， 按照该单元的读取进度信 息接续读取该单元的操作日志文件中的修改请求， 并按照读取的修改请求修改数据库中的 长关系链数据。 这样可以进一步保证入库模块由于故障、 运维动作等导致的停机重启后， 可 以快速自动恢复到停机前的读取进度， 降低了运营维护的难度。 0044 具体的， 所述入库模块中具体包括读取进度记录模块， 用于记录所述读取进度信 息， 每读取一单元的操作日志文件中的一条记录， 就把对应单元的读取进度加 1， 从而实现 记录对该单元操作日志。

34、文件中的修改请求的读取进度信息。 0045 与上述系统对应， 本发明还公开了对用户的长关系链数据的处理方法， 由所述系 统执行。图 3 为本发明所述对用户的长关系链数据的处理方法的一种流程图。参见图 3， 该 方法包括 ： 0046 301、 缓存模块响应前端对所述用户的长关系链数据的操作请求， 将其中的修改请 求同步发送给后述的接收模块。 0047 302、 接收模块接收来自所述缓存模块的修改请求， 将所述修改请求同步保存到非 内存存储设备的操作日志文件中。 0048 303、 入库模块读取所述接收模块的操作日志文件中的修改请求， 并按照读取的修 改请求修改数据库中的长关系链数据。 0049。

35、 为了进一步方便模块和数据的扩展扩容， 提升运营维护效率， 在进一步的实施例 中， 该方法进一步包括 ： 0050 对用户人群进行单元划分， 将单元信息通知给所述缓存模块、 接收模块和入库模 块。所述对用户人群进行单元划分， 就是将用户人群进行分组， 每一组称为一个单元。所述 对用户人群进行单元划分的具体方法例如可以包括 ： 设置指定的单元大小， 对系统内的用 户按顺序编号， 对所述用户的编号利用所述单元大小取模值， 模值相同的用户属于同一单 元， 或者对所述用户的编号利用所述单元大小取整， 整数相同的用户属于同一单元。 0051 所述缓存模块进一步区分发起所述修改请求的用户所属的单元， 将所。

36、述修改请求 及其单元信息同步发送给所述接收模块 ； 所述接收模块进一步为不同的单元分别对应建立 至少一个操作日志文件， 将所述修改请求同步保存到该修改请求对应单元的操作日志文件 中 ； 所述入库模块进一步按照所述单元信息为不同的单元对应建立不同的数据库， 并在修 改数据库时， 按照读取的修改请求修改该修改请求对应单元的数据库中的长关系链数据。 说 明 书 CN 103838757 A 8 6/7 页 9 0052 在一种实施例中， 本发明的方法还可以进一步包括 ： 0053 所述接收模块针对每一单元， 在内存中记录同步保存所述修改请求的同步进度信 息， 并将所述同步进度信息反馈给所述缓存模块。。

37、所述在内存中记录同步保存所述修改请 求的同步进度信息的具体方式包括 ： 每次操作操作日志文件同步保存一条修改请求完毕 后， 就把该操作日志文件对应单元的同步进度信息加 1。 0054 在本接收模块停机重启后， 针对每一单元， 扫描该单元的操作日志文件， 根据该单 元最新的操作日志文件恢复该单元的同步进度信息， 并将该单元的同步进度信息反馈给所 述缓存模块 ； 所述缓存模块根据所述接收模块反馈的各个单元的进度信息同步发送对应单 元的、 该进度之后的修改请求给所述接收模块。所述根据单元的最新的操作日志文件恢复 同步进度信息， 具体包括 ： 确定该单元的保存时间在该最新的操作日志文件之前的操作日 志。

38、文件数目m， 将该数目乘以一个操作日志文件的记录容量n， 将mn作为该单元的同步进 度信息。 0055 在又一种实施例中， 本发明所述的方法还可以进一步包括 ： 0056 所述入库模块针对每一单元， 在内存中记录对该单元操作日志文件中的修改请求 的读取进度信息， 每读完一个操作日志文件则标记该文件已读。所述在内存中记录对该单 元操作日志文件中的修改请求的读取进度信息的具体方式包括 ： 每读取一单元的操作日志 文件中的一条记录， 就把对应单元的读取进度加 1。 0057 在本入库模块停机重启后， 针对每一单元， 扫描该单元的操作日志文件， 根据保存 时间最久的未读操作日志文件恢复该单元的读取进度。

39、信息， 按照该单元的读取进度信息接 续读取该单元的操作日志文件中的修改请求， 并按照读取的修改请求修改数据库中的长关 系链数据。 所述根据保存时间最久的未读操作日志文件恢复单元的读取进度信息的具体方 法包括 ： 确定该单元的保存时间最久的未读操作日志文件之前的操作日志文件数目 M， 将 该数目乘以一个操作日志文件的记录容量 n， 将 Mn 作为该单元的读取进度信息。 0058 下面以一个更为具体的实施例， 进一步描述本发明所述的方法。图 4 为本发明所 述具体实施例的一种流程图。参见图 2 和图 4， 假设预先根据指定单元大小 （如 4999） 对系 统内的所有用户进行了单元划分， 该流程包括。

40、 ： 0059 步骤 401、 Cache 模块 （即缓存模块） 以指定单元大小为单元单位将来自前端的对 用户长关系链数据的修改请求同步发送给接收模块。 0060 步骤 402、 接收模块接收 cache 模块同步发送来的修改请求， 区分该修改请求的单 元， 并将该修改请求作为操作日志记录到该单元对应的操作日志中， 形成操作日志文件。 0061 步骤 403、 每次操作操作日志文件同步保存一条修改请求完毕后， 就把该操作日志 文件对应单元的同步进度信息加 1， 并通知 Cache 模块同步发送该单元的下一个修改请求。 0062 步骤 404、 入库模块以单元为单位扫描并读取所述接收模块中的操作。

41、日志文件。 0063 步骤 405、 入库模块根据所述每个单元对应的操作日志文件中记录的修改请求来 对相应单元的底层数据库进行修改操作。 0064 步骤 406、 入库模块每读取一单元的操作日志文件中的一条记录， 就把对应单元的 读取进度加 1。 0065 步骤 407、 入库模块每读取完一个操作日志文件， 就对这个操作日志文件标记已 读。 说 明 书 CN 103838757 A 9 7/7 页 10 0066 图5为图4所述实施例中当接收模块因为运维动作、 机器重启、 模块异常而重启时 的流程图。参见图 5， 该流程具体包括 ： 0067 步骤 410、 接收模块重启。 0068 步骤 4。

42、11、 接收模块以所述单元为单位， 针对每一单元， 扫描该单元的操作日志文 件。 0069 步骤 412、 根据每一单元最新的操作日志文件恢复该单元的同步进度信息， 并将该 单元的同步进度信息反馈给所述缓存模块。例如具体为 ： 确定该单元的保存时间在该最新 的操作日志文件之前的操作日志文件数目 m， 将该数目乘以一个操作日志文件的记录容量 n， 将 mn 作为该单元的同步进度信息。 0070 步骤 413、 所述缓存模块根据所述接收模块反馈的各个单元的进度信息同步发送 对应单元的、 该进度之后的修改请求给所述接收模块。 0071 图6为图4所述实施例中当入库模块因为运维动作、 机器重启、 模块。

43、异常而重启时 的流程图。参见图 6， 该流程具体包括 ： 0072 步骤 420、 入库模块重启。 0073 步骤 421、 入库模块以所述单元为单元， 针对每一单元， 扫描该单元的操作日志文 件。 0074 步骤 422、 入库模块根据保存时间最久的未读操作日志文件恢复该单元的读取进 度信息。例如具体为 ： 确定该单元的保存时间最久的未读操作日志文件之前的操作日志文 件数目M， 将该数目乘以一个操作日志文件的记录容量n， 将Mn作为该单元的读取进度信 息。 0075 步骤 423、 入库模块按照各单元的读取进度信息接续读取该单元的操作日志文件 中的修改请求， 例如从第 M+1 个操作日志文件。

44、开始读取修改请求， 并按照读取的修改请求 修改数据库中的长关系链数据。 0076 以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡在本发明的精 神和原则之内， 所做的任何修改、 等同替换、 改进等， 均应包含在本发明保护的范围之内。 说 明 书 CN 103838757 A 10 1/4 页 11 图 1 图 2 说 明 书 附 图 CN 103838757 A 11 2/4 页 12 图 3 说 明 书 附 图 CN 103838757 A 12 3/4 页 13 图 4 图 5 说 明 书 附 图 CN 103838757 A 13 4/4 页 14 图 6 说 明 书 附 图 CN 103838757 A 14 。