对用户的长关系链数据的处理系统和方法
【专利摘要】本申请公开了一种对用户的长关系链数据的处理系统和方法，包括：缓存模块响应前端对所述用户的长关系链数据的操作请求，将其中的修改请求同步发送给后述的接收模块；接收模块接收来自所述缓存模块的修改请求，将所述修改请求同步保存到非内存存储设备的操作日志文件中；入库模块读取所述接收模块的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。利用本发明，可以以降低丢失修改请求的几率，降低数据库中的长关系链数据的数据错误率。
【专利说明】对用户的长关系链数据的处理系统和方法
【技术领域】
[0001]本申请涉及计算机和互联网数据处理【技术领域】，尤其涉及一种对用户的长关系链数据的处理系统和方法。
【背景技术】
[0002]目前，随着互联网技术的发展，网络逐渐成为人们获取信息的重要来源，特别是在互联网进入Web2.0时代后，用户既是网站内容的浏览者，也是网站内容的制造者。用户参与创造的内容被称为用户生成内容(UGC, User Generated Content),如用户发布的日志、照片等，在Web2.0时代，由于UGC的大量涌现，网络信息量呈几何级快速增长。
[0003]目前最活跃的网络通信系统之一就是社交网络服务系统(SNS，SocialNetworkService)0 SNS简称为社交网络系统，是旨在帮助人们建立社会性网络的互联网应用服务系统。目前几乎所有的网站系统都在扩展其社交便利性，为其增加SNS特性，本文中将所有具有SNS特性的网站系统称为社交网络系统，例如:网上社区系统、博客系统、微博客系统(简称微博)等。
[0004]在SNS中，每个用户都是信息的发布者，几乎时时刻刻都在生产出大量的UGC。而且每个用户都有其自身的关系链，所述用户关系链主要包括在SNS中能和该用户进行互动的用户群体，用户关系链数据中包括这个群体中的每一个用户的标识、属性等信息，以及每一个用户与主用户的关系。其中，有些用户的关系链中的用户数量巨大，这种关系链在业界被称为长关系链，拥有长关系链的用户被称为长关系链用户。
[0005]例如，微博客(MicroBlog)，简称微博，是一个基于用户关系的信息分享、传播以及获取的SNS系统，用户可以通过有线通信网络或无线通信网络、以及各种客户端访问微博，以指定数目的文字和/或其它多媒体信息更新信息，并实现即时分享。在微博系统中，每一个用户都可以收听(或关注)其它用户，即被该用户收听(或关注)的用户所发布的微博信息(即UGC)可以及时地传输到该用户的微博中，收听者就是被收听者的“听众”(有些微博系统中也叫“粉丝”，本文中以听众为例进行说明)。当然所有的用户也可以被其它用户收听(或关注)。当某一用户的听众的数量超过一定数目之后，则该用户就变成了长关系链用户，例如微博中的一些明星用户，其听众的数量往往有几百万甚至上千万。
[0006]在生产UGC的SNS中，由于数据是用户产生的，海量的用户催生出海量数据，最终带来更大量级的数据读写请求。特别是长关系链用户的数据处理，由于其长关系链中包括百万级甚至千万级数量的听众，添加或删除一个听众也要对被收听用户的长关系链进行相应的数据修改，因此针对长关系链数据的请求的数量巨大，触发频繁，导致对相应的数据库的操作量也巨大和频繁。因此对用户的长关系链数据需要特殊的处理。
[0007]图1现有技术中的一种针对长关系链用户数据的处理系统。参见图1，该系统中主要包括缓存(cache )模块和入库模块。所述数据库中保存了长关系链用户的全量长关系链数据，例如微博系统中是全量的听众列表，而由于长关系链用户读取微博并不需要全量听众列表，并为了向前端极速的响应这类长关系链用户的对听众列表的读取请求，因此将每一长关系链用户的一部分听众列表按更新时间保存在内存的缓存模块中，该缓存模块用于响应前端(如客户端，网页前端，即用户操作端)对所述长关系链用户的长关系链数据的操作请求，由于内存操作迅速，因此可以极速响应长关系链用户对关系链数据的读取请求。对于写操作请求，即需要对相应数据库进行入库修改的修改请求，则需要将这些修改请求同步给所述入库模块，由入库模块根据这些修改请求修改数据库中的数据。
[0008]但是上述现有技术具有如下缺点:
[0009]由于缓存模块是纯内存操作，入库模块是直接对底层数据库进行操作，而操作数据库和纯内存操作的速度不是一个数量级，速度相差太悬殊。为了解决Cache模块和入库模块速度的不一致，缓存模块必须长时间保存对长关系链用户的操作日志，直到入库模块完成对数据库的操作才能释放操作日志占用的空间，因此现有技术对用户的长关系链数据的入库存储需要严重依赖缓存模块，不但占用了缓存模块的大量内存空间，而且一旦缓存模块出现异常重启则会清空内存，进而丢失大量的修改请求，导致数据库中的长关系链数据与前端操作严重不符，数据错误率高。
【发明内容】
[0010]有鉴于此，本发明的主要目的在于提供一种对用户的长关系链数据的处理系统和方法，以降低丢失修改请求的几率，降低数据库中的长关系链数据的数据错误率。
[0011]本发明的技术方案是这样实现的:
[0012]一种对用户的长关系链数据的处理系统，包括:
[0013]缓存模块，设置在内存中，用于响应前端对所述用户的长关系链数据的操作请求，将其中的修改请求同步发送给后述的接收模块；
[0014]接收模块，用于接收来自所述缓存模块的修改请求，将所述修改请求同步保存到非内存存储设备的操作日志文件中；
[0015]入库模块，用于读取所述接收模块的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
[0016]一种对用户的长关系链数据的处理方法，包括:
[0017]缓存模块响应前端对所述用户的长关系链数据的操作请求，将其中的修改请求同步发送给后述的接收模块；
[0018]接收模块接收来自所述缓存模块的修改请求，将所述修改请求同步保存到非内存存储设备的操作日志文件中；
[0019]入库模块读取所述接收模块的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
[0020]与现有技术相比，本发明引入了接收模块，缓存模块将前端的对用户长关系链数据的修改请求同步给该接收模块，由该接收模块将所述修改请求同步保存在非内存存储设备的操作日志文件中，而入库模块不是从缓存模块获取前端的修改请求，而是通过读取所述接收模块的操作日志文件来获取修改请求，并根据修改请求修改数据库中的长关系链数据。因此，本发明将所述缓存模块和入库模块成功解耦，通过增加一个接收模块，来协调快速的修改请求和慢速的数据库操作，从缓存模块同步修改请求到接收模块的同步速度较快，而接收模块中的操作日志文件又可以长时间保存供入库模块读取，因此缓存模块不必长时间保存对长关系链用户的操作日志，降低缓存模块对内存空间的占用，也降低了由于缓存模块异常重启导致丢失修改请求的几率，进而保证数据库中的长关系链数据与前端操作的符合程度，降低了数据库中的长关系链数据的数据错误率。
【专利附图】
【附图说明】
[0021]图I现有技术中的一种针对用户的长关系链数据的处理系统；
[0022]图2为本发明所述对用户的长关系链数据的处理系统的一种组成示意图；
[0023]图3为本发明所述对用户的长关系链数据的处理方法的一种流程图；
[0024]图4为本发明所述具体实施例的一种流程图；
[0025]图5为图4所述实施例中当接收模块因为运维动作、机器重启、模块异常而重启时的流程图；
[0026]图6为图4所述实施例中当入库模块因为运维动作、机器重启、模块异常而重启时的流程图。
【具体实施方式】
[0027]下面结合附图及具体实施例对本发明再作进一步详细的说明
[0028]图2为本发明所述对用户的长关系链数据的处理系统的一种组成示意图。参见图2，该处理系统包括缓存（cache)模块201、接收模块202、以及入库模块203。
[0029]所述缓存模块201设置在内存中，在该缓存模块201中缓存了长关系链用户的最新更新的一部分长关系链数据，用于响应前端(如客户端，网页前端，即用户操作端）对所述用户的长关系链数据的操作请求，针对其中大部分的读取请求，可以直接从该缓存模块201中读取并将读取结果返回给前端，从而实现长关系链用户的关系链数据的极速读取响应。而对于前端对所述用户的长关系链数据的修改请求，例如微博系统中的添加听众请求、删除听众请求、修改听众请求，则将这些修改请求同步发送给所述接收模块202。
[0030]所述接收模块202用于接收来自所述缓存模块201的修改请求，将所述修改请求作为日志记录同步保存到非内存存储设备的操作日志文件（Binlog)中，即该操作日志文件不是保存在内存中，而是保存在诸如硬盘等存储设备中。由于对长关系链用户的长关系链数据的修改请求规模巨大，因此可以在一个操作日志文件写满后，增加新的操作日志文件来保存所述修改请求。写操作日志文件的速度要比操作数据库的速度快很多，与读取内存的速度相差不多，因此缓存模块201中接收到的修改请求可以快速地同步给接收模块203。
[0031]所述入库模块203用于操作数据库（DB)，具体用于读取所述接收模块202的操作日志文件中的一条条的日志记录即修改请求，并按照读取的修改请求修改数据库中的长关系链数据。例如如果是向该长关系链用户添加听众的请求，则在数据库中的该用户的长关系链数据中添加所述听众。
[0032]由于操作底层数据库的操作与内存操作的速度相差很多，因此入库模块203需要较长时间地读取所述接收模块202的操作日志文件，而所述操作日志文件保存在非内存的存储设备中，即使由于故障、维修等原因停机，这些操作日志文件也不会丢失，降低了修改请求的丢失几率，进而保证数据库中的长关系链数据与前端操作的符合程度，降低了数据库中的长关系链数据的数据错误率。同时，所述内存中的缓存模块201能够快速地将对用户的长关系链数据的修改请求同步给所述接收模块202，因此缓存模块201不必长时间保存对长关系链用户的操作日志，降低缓存模块202对内存空间的占用。
[0033]另外，图1所示的现有技术中还存在模块扩展难的缺陷，即现有技术中的入库模块只会把长关系链用户的长关系链数据保存到一个数据库里。当系统的数据量增大后，需要进行系统扩容，在扩容时必须重新创建一套入库模块和容量更大的数据库，然后将原有数据库中的数据全部迁移到新的数据库中。这种每扩展一次就要进行全量的数据迁移造成了对系统设备运营维护的困难。
[0034]作为一种改进，在本发明的一种实施例中，所述对用户的长关系链数据的处理系统还进一步包括划分用户模块，用于对用户人群进行单元划分，将单元(Unit)信息通知给所述缓存模块201、接收模块202和入库模块203。所述对用户人群进行单元划分，就是将用户人群进行分组，每一组称为一个单元，这样方便扩展。
[0035]在该实施例中，所述缓存模块201进一步用于:区分发起所述修改请求的用户所属的单元，将所述修改请求及其单元信息同步发送给所述接收模块。
[0036]所述接收模块202进一步用于:为不同的单元分别对应建立至少一个操作日志文件，如图2所示，并将所述修改请求同步保存到该修改请求对应单元的操作日志文件中。对于某一个单元，可以在一个操作日志文件写满后，增加新的操作日志文件来保存该单元对应的修改请求。
[0037]所述入库模块进一步用于:按照所述单元信息为不同的单元对应建立不同的数据库，如图2所示，并在修改数据库时，按照读取的修改请求修改该修改请求对应单元的数据库中的长关系链数据。
[0038]本发明通过对用户群体进行单元划分，形成了最小的处理单元，在对用户的长关系链数据的处理过程中，接收模块202和入库模块203都是按照单元为单位处理修改请求和存储入库的。当SNS系统中的用户总量攀升后，可以将新增的用户划分到新的单元中，在需要扩容接收模块202和入库模块203时，可以新增处理设备(如服务器)放置新扩容的接收模块和入库模块以及数据库，只需要把要迁移的单元的操作日志文件复制到新增的接收模块中，并开启新增的接收模块和入库模块和数据库，然后在所述缓存模块中添加新增的接收模块的路由信息，以使缓存模块可以将该新单元的修改请求同步发送给新的接收模块。如果要扩容数据库，只需求停止入库模块的运行，把原数据库数据复制到目的地或增加新增单元对应的数据库，修改入库模块中的新增数据库的路由信息，然后开启入库模块即可。
[0039]本发明由于采用了分单元处理，方便接收模块、入库模块以及数据库的扩展扩容，因此运营维护简单。同时，由于可以非常方便地扩展扩容相关设备，因此可以对突发的数据量暴增作出及时的设备扩展扩容处理，从而保证整个SNS系统对前端数据请求的较快的响应速度。
[0040]这本发明的又一种实施例中，所述接收模块202进一步用于:针对每一单元，在内存中记录同步保存所述修改请求的同步进度信息，并将所述同步进度信息反馈给所述缓存模块201 ;在本接收模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据该单元最新的操作日志文件恢复该单元的同步进度信息，并将该单元的同步进度信息反馈给所述缓存模块。所述缓存模块201进一步用于:根据所述接收模块反馈的各个单元的进度信息同步发送对应单元的、该进度之后的修改请求给所述接收模块。
[0041]例如，接收模块返回的第i个单元的进度信息为第1000条，则缓存模块收到该进度反馈后再发送该第i个单元的第1001条修改请求及其后续的修改请求。因此可以进一步保证接收模块由于故障、运维动作等导致的停机重启后，可以快速自动同步在所述接收模块停机期间未同步成功的修改请求，降低了运营维护的难度。
[0042]具体的，所述接收模块中具体包括同步进度记录模块，用于记录所述同步进度信息，在每次操作操作日志文件同步保存一条修改请求完毕，就把该操作日志对应单元的同步进度信息加I，从而实现记录同步保存所述修改请求的同步进度信息。
[0043]在又一种实施例中，所述入库模块也可以进一步用于:针对每一单元，在内存中记录对该单元操作日志文件中的修改请求的读取进度信息，每读完一个操作日志文件则标记该文件已读；在本入库模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据保存时间最久的未读操作日志文件恢复该单元的读取进度信息，按照该单元的读取进度信息接续读取该单元的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。这样可以进一步保证入库模块由于故障、运维动作等导致的停机重启后，可以快速自动恢复到停机前的读取进度，降低了运营维护的难度。
[0044]具体的，所述入库模块中具体包括读取进度记录模块，用于记录所述读取进度信息，每读取一单元的操作日志文件中的一条记录，就把对应单元的读取进度加1，从而实现记录对该单元操作日志文件中的修改请求的读取进度信息。
[0045]与上述系统对应，本发明还公开了对用户的长关系链数据的处理方法，由所述系统执行。图3为本发明所述对用户的长关系链数据的处理方法的一种流程图。参见图3，该方法包括:
[0046]301、缓存模块响应前端对所述用户的长关系链数据的操作请求，将其中的修改请求同步发送给后述的接收模块。
[0047]302、接收模块接收来自所述缓存模块的修改请求，将所述修改请求同步保存到非内存存储设备的操作日志文件中。
[0048]303、入库模块读取所述接收模块的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
[0049]为了进一步方便模块和数据的扩展扩容，提升运营维护效率，在进一步的实施例中，该方法进一步包括:
[0050]对用户人群进行单元划分，将单元信息通知给所述缓存模块、接收模块和入库模块。所述对用户人群进行单元划分，就是将用户人群进行分组，每一组称为一个单元。所述对用户人群进行单元划分的具体方法例如可以包括:设置指定的单元大小，对系统内的用户按顺序编号，对所述用户的编号利用所述单元大小取模值，模值相同的用户属于同一单元，或者对所述用户的编号利用所述单元大小取整，整数相同的用户属于同一单元。
[0051]所述缓存模块进一步区分发起所述修改请求的用户所属的单元，将所述修改请求及其单元信息同步发送给所述接收模块；所述接收模块进一步为不同的单元分别对应建立至少一个操作日志文件，将所述修改请求同步保存到该修改请求对应单元的操作日志文件中；所述入库模块进一步按照所述单元信息为不同的单元对应建立不同的数据库，并在修改数据库时，按照读取的修改请求修改该修改请求对应单元的数据库中的长关系链数据。[0052]在一种实施例中，本发明的方法还可以进一步包括:
[0053]所述接收模块针对每一单元，在内存中记录同步保存所述修改请求的同步进度信息，并将所述同步进度信息反馈给所述缓存模块。所述在内存中记录同步保存所述修改请求的同步进度信息的具体方式包括:每次操作操作日志文件同步保存一条修改请求完毕后，就把该操作日志文件对应单元的同步进度信息加I。
[0054]在本接收模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据该单元最新的操作日志文件恢复该单元的同步进度信息，并将该单元的同步进度信息反馈给所述缓存模块；所述缓存模块根据所述接收模块反馈的各个单元的进度信息同步发送对应单元的、该进度之后的修改请求给所述接收模块。所述根据单元的最新的操作日志文件恢复同步进度信息，具体包括:确定该单元的保存时间在该最新的操作日志文件之前的操作日志文件数目m，将该数目乘以一个操作日志文件的记录容量n，将mXn作为该单元的同步进度?目息。
[0055]在又一种实施例中，本发明所述的方法还可以进一步包括:
[0056]所述入库模块针对每一单元，在内存中记录对该单元操作日志文件中的修改请求的读取进度信息，每读完一个操作日志文件则标记该文件已读。所述在内存中记录对该单元操作日志文件中的修改请求的读取进度信息的具体方式包括:每读取一单元的操作日志文件中的一条记录，就把对应单元的读取进度加I。
[0057]在本入库模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据保存时间最久的未读操作日志文件恢复该单元的读取进度信息，按照该单元的读取进度信息接续读取该单元的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。所述根据保 存时间最久的未读操作日志文件恢复单元的读取进度信息的具体方法包括:确定该单元的保存时间最久的未读操作日志文件之前的操作日志文件数目1?，将该数目乘以一个操作日志文件的记录容量η，将MXn作为该单元的读取进度信息。
[0058]下面以一个更为具体的实施例，进一步描述本发明所述的方法。图4为本发明所述具体实施例的一种流程图。参见图2和图4，假设预先根据指定单元大小(如4999)对系统内的所有用户进行了单元划分，该流程包括:
[0059]步骤401、Cache模块(即缓存模块)以指定单元大小为单元单位将来自前端的对用户长关系链数据的修改请求同步发送给接收模块。
[0060]步骤402、接收模块接收cache模块同步发送来的修改请求,区分该修改请求的单元，并将该修改请求作为操作日志记录到该单元对应的操作日志中，形成操作日志文件。
[0061]步骤403、每次操作操作日志文件同步保存一条修改请求完毕后，就把该操作日志文件对应单元的同步进度信息加I，并通知Cache模块同步发送该单元的下一个修改请求。
[0062]步骤404、入库模块以单元为单位扫描并读取所述接收模块中的操作日志文件。
[0063]步骤405、入库模块根据所述每个单元对应的操作日志文件中记录的修改请求来对相应单元的底层数据库进行修改操作。
[0064]步骤406、入库模块每读取一单元的操作日志文件中的一条记录，就把对应单元的读取进度加I。
[0065]步骤407、入库模块每读取完一个操作日志文件，就对这个操作日志文件标记已读。[0066]图5为图4所述实施例中当接收模块因为运维动作、机器重启、模块异常而重启时的流程图。参见图5，该流程具体包括:
[0067]步骤410、接收模块重启。
[0068]步骤411、接收模块以所述单元为单位，针对每一单元，扫描该单元的操作日志文件。
[0069]步骤412、根据每一单元最新的操作日志文件恢复该单元的同步进度信息，并将该单元的同步进度信息反馈给所述缓存模块。例如具体为:确定该单元的保存时间在该最新的操作日志文件之前的操作日志文件数目III，将该数目乘以一个操作日志文件的记录容量II，将111X11作为该单元的同步进度信息。
[0070]步骤413、所述缓存模块根据所述接收模块反馈的各个单元的进度信息同步发送对应单元的、该进度之后的修改请求给所述接收模块。
[0071]图6为图4所述实施例中当入库模块因为运维动作、机器重启、模块异常而重启时的流程图。参见图6，该流程具体包括:
[0072]步骤420、入库模块重启。
[0073]步骤421、入库模块以所述单元为单元，针对每一单元，扫描该单元的操作日志文件。
[0074]步骤422、入库模块根据保存时间最久的未读操作日志文件恢复该单元的读取进度信息。例如具体为:确定该单元的保存时间最久的未读操作日志文件之前的操作日志文件数目1，将该数目乘以一个操作日志文件的记录容量II，将IX 作为该单元的读取进度信
肩、0
[0075]步骤423、入库模块按照各单元的读取进度信息接续读取该单元的操作日志文件中的修改请求，例如从第1+1个操作日志文件开始读取修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
[0076]以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。
【权利要求】
1.一种对用户的长关系链数据的处理系统，其特征在于，包括: 缓存模块，设置在内存中，用于响应前端对所述用户的长关系链数据的操作请求，将其中的修改请求同步发送给后述的接收模块； 接收模块，用于接收来自所述缓存模块的修改请求，将所述修改请求同步保存到非内存存储设备的操作日志文件中； 入库模块，用于读取所述接收模块的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
2.根据权利要求1所述的系统，其特征在于，该系统进一步包括:划分用户模块，用于对用户人群进行单元划分，将单元信息通知给所述缓存模块、接收模块和入库模块； 所述缓存模块进 一步用于:区分发起所述修改请求的用户所属的单元，将所述修改请求及其单元信息同步发送给所述接收模块； 所述接收模块进一步用于:为不同的单元分别对应建立至少一个操作日志文件，将所述修改请求同步保存到该修改请求对应单元的操作日志文件中； 所述入库模块进一步用于:按照所述单元信息为不同的单元对应建立不同的数据库，并在修改数据库时，按照读取的修改请求修改该修改请求对应单元的数据库中的长关系链数据。
3.根据权利要求2所述的系统，其特征在于， 所述接收模块进一步用于:针对每一单元，在内存中记录同步保存所述修改请求的同步进度信息，并将所述同步进度信息反馈给所述缓存模块；在本接收模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据该单元最新的操作日志文件恢复该单元的同步进度信息，并将该单元的同步进度信息反馈给所述缓存模块； 所述缓存模块进一步用于:根据所述接收模块反馈的各个单元的进度信息同步发送对应单元的、该进度之后的修改请求给所述接收模块。
4.根据权利要求3所述的系统，其特征在于，所述接收模块中具体包括同步进度记录模块，用于记录所述同步进度信息，在每次操作操作日志文件同步保存一条修改请求完毕，就把该操作日志对应单元的同步进度信息加1。
5.根据权利要求2所述的系统，其特征在于， 所述入库模块进一步用于:针对每一单元，在内存中记录对该单元操作日志文件中的修改请求的读取进度信息，每读完一个操作日志文件则标记该文件已读；在本入库模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据保存时间最久的未读操作日志文件恢复该单元的读取进度信息，按照该单元的读取进度信息接续读取该单元的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
6.根据权利要求5所述的系统，其特征在于，所述入库模块中具体包括读取进度记录模块，用于记录所述读取进度信息，每读取一单元的操作日志文件中的一条记录，就把对应单元的读取进度加1。
7.一种对用户的长关系链数据的处理方法，其特征在于，包括: 缓存模块响应前端对所述用户的长关系链数据的操作请求，将其中的修改请求同步发送给后述的接收模块； 接收模块接收来自所述缓存模块的修改请求，将所述修改请求同步保存到非内存存储设备的操作日志文件中； 入库模块读取所述接收模块的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
8.根据权利要求7所述的方法，其特征在于，该方法进一步包括: 对用户人群进行单元划分，将单元信息通知给所述缓存模块、接收模块和入库模块； 所述缓存模块进一步区分发起所述修改请求的用户所属的单元，将所述修改请求及其单元信息同步发送给所述接收模块； 所述接收模块进一步为不同的单元分别对应建立至少一个操作日志文件，将所述修改请求同步保存到该修改请求对应单元的操作日志文件中； 所述入库模块进一步按照所述单元信息为不同的单元对应建立不同的数据库，并在修改数据库时，按照读取的修改请求修改该修改请求对应单元的数据库中的长关系链数据。
9.根据权利要求8所述的方法，其特征在于，该方法进一步包括: 所述接收模块针对每一单元，在内存中记录同步保存所述修改请求的同步进度信息，并将所述同步进度信息反馈给所述缓存模块；在本接收模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据该单元最新的操作日志文件恢复该单元的同步进度信息，并将该单元的同步进度信息反馈给所述缓存模块； 所述缓存模块根据所述接收模块反馈的各个单元的进度信息同步发送对应单元的、该进度之后的修改请求给所述接收模块。
10.根据权利要求9所述的方法，其特征在于，所述在内存中记录同步保存所述修改请求的同步进度信息，具体包括:每次操作操作日志文件同步保存一条修改请求完毕后，就把该操作日志文件对应单元的同步进度信息加I。
11.根据权利要求9所述的方法，其特征在于，所述根据单元的最新的操作日志文件恢复同步进度信息，具体包括:确定该单元的保存时间在该最新的操作日志文件之前的操作日志文件数目m，将该数目乘以一个操作日志文件的记录容量n，将mXn作为该单元的同步进度信息。
12.根据权利要求8所述的方法，其特征在于，该方法进一步包括: 所述入库模块针对每一单元，在内存中记录对该单元操作日志文件中的修改请求的读取进度信息，每读完一个操作日志文件则标记该文件已读；在本入库模块停机重启后，针对每一单元，扫描该单元的操作日志文件，根据保存时间最久的未读操作日志文件恢复该单元的读取进度信息，按照该单元的读取进度信息接续读取该单元的操作日志文件中的修改请求，并按照读取的修改请求修改数据库中的长关系链数据。
13.根据权利要求12所述的方法，其特征在于，所述在内存中记录对该单元操作日志文件中的修改请求的读取进度信息，具体包括:每读取一单元的操作日志文件中的一条记录，就把对应单元的读取进度加I。
14.根据权利要求12所述的方法，其特征在于，所述根据保存时间最久的未读操作日志文件恢复单元的读取进度信息，具体包括:确定该单元的保存时间最久的未读操作日志文件之前的操作日志文件数目M,将该数目乘以一个操作日志文件的记录容量n，将MXn作为该单元的读取进度信息。
【文档编号】G06F17/30GK103838757SQ201210483647
【公开日】2014年6月4日 申请日期:2012年11月26日 优先权日:2012年11月26日
【发明者】王辉 申请人:腾讯科技（深圳）有限公司