CN110019260B - 一种用户数据的更新方法及相关设备 - Google Patents

一种用户数据的更新方法及相关设备 Download PDF

Info

Publication number
CN110019260B
CN110019260B CN201710895754.1A CN201710895754A CN110019260B CN 110019260 B CN110019260 B CN 110019260B CN 201710895754 A CN201710895754 A CN 201710895754A CN 110019260 B CN110019260 B CN 110019260B
Authority
CN
China
Prior art keywords
list
openid
user
public number
wechat public
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710895754.1A
Other languages
English (en)
Other versions
CN110019260A (zh
Inventor
陈玉萍
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Gridsum Technology Co Ltd
Original Assignee
Beijing Gridsum Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Gridsum Technology Co Ltd filed Critical Beijing Gridsum Technology Co Ltd
Priority to CN201710895754.1A priority Critical patent/CN110019260B/zh
Publication of CN110019260A publication Critical patent/CN110019260A/zh
Application granted granted Critical
Publication of CN110019260B publication Critical patent/CN110019260B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请实施例公开了一种用户数据的更新方法及相关设备，用于增加微信公众号中的更新用户数据的方式。基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；其中，所述增量同步用于对所述目标微信公众号的新增关注用户的基本信息数据字符串进行同步，所述全量同步用于对所述目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔。

Description

一种用户数据的更新方法及相关设备
技术领域
本申请涉及数据处理领域，特别涉及一种用户数据的更新方法及相关设备。
背景技术
微信是腾讯公司于2011年1月21日推出的一个为智能终端提供即时通讯服务的免费应用程序，微信公众号是开发者或商家在微信平台上申请的应用账号，该账号与QQ账号互通，通过公众号，商家可在微信平台上实现和特定群体的文字、图片、语音、视频的全方位沟通、互动。形成了一种主流的线上线下微信互动营销方式。
现今，微信已成为亚洲地区最大用户群体的移动即时通讯软件。微信营销也伴随着微信的火热而成为一种炙手可热的新型网络营销方式。而微信粉丝数也成为众多公众号衡量运营成果的标准之一。通过调用微信公众号API (Application ProgrammingInterface，应用程序编程接口)可以实现微信用户基本信息的获取，从而可以对用户数据进行分析、评估，推进微信运营的发展。
在每天同步微信公众号用户数据时，每次都是从微信公众号API中同步公众号的所有粉丝数据，当公众号的粉丝数很大时，比如100万+，每次同步用户数据需要花费很长时间，影响其他类型微信数据的同步，而事实上微信用户数据的基本信息(如头像、昵称、性别、地区)等信息不会频繁修改，所以每次都全量同步公众号粉丝数据是不必要的。
发明内容
本申请实施例提供了一种用户数据的更新方法及相关设备，用于提高微信公众号的用户数据的同步效率，解决公众号用户数据量很大时的性能瓶颈。
本申请实施例第一方面提供了一种用户数据的更新方法，具体包括：
基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；
其中，所述增量同步用于对所述目标微信公众号的新增关注用户的基本信息数据字符串进行同步，所述全量同步用于对所述目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔。
在第一方面的一种实施方式中，所述对目标微信公众号对应的数据库周期性的进行增量同步之后，所述方法还包括：
在每次进行所述增量同步后，在用户记录表中保存当前增量同步所确定的关注所述目标微信公众号的用户数量；
判断进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；
若是，则触发执行所述全量同步。
在第一方面的一种实施方式中，所述对目标微信公众号对应的数据库周期性的进行增量同步包括：
获取第一OpenId列表，所述第一OpenId列表为所述目标微信公众号中新增用户的OpenId列表；
根据所述第一OpenId列表获取所述新增用户的第一用户基本信息数据字符串；
将所述第一用户基本信息数据字符串转换成第一用户类型对象；
对所述第一用户类型对象进行处理，并将处理后第一用户类型对象更新至所述目标微信公众号对应的数据库。
在第一方面的一种实施方式中，所述对所述目标微信公众号对应的数据库周期性的进行的全量同步包括：
获取第二OpenId列表，所述第二OpenId列表为所述目标微信公众号中第一所有用户的OpenId列表，所述第一所有用户的OpenId列表通过调用所述目标微信公众号的应用程序编程接口API获取；
根据所述第二OpenId列表获取所述第一所有用户的第二用户基本信息数据字符串；
将所述第二用户基本信息数据字符串转换为第二用户类型对象；
对所述第二用户类型对象进行处理，并将处理后的第二用户类型对象更新至所述目标微信公众号对应的数据库。
在第一方面的一种实施方式中，所述获取第一OpenId列表包括：
获取第三OpenId列表，所述第三OpenId列表为所述目标微信公众号中第二所有用户的OpenId列表，所述第二所有用户的OpenId列表是通过调用所述目标微信公众号的API接口获取；
获取所述第四OpenId列表，所述第四OpenId列表为所述目标微信公众号中第一未取消关注的用户的OpenId列表，所述第一未取消关注的用户的标识列表从所述目标微信公众号对应的数据库中获取；
将所述第三OpenId列表与所述第四OpenId列表按照第一对比规则进行对比，以得到所述第一OpenId列表。
在第一方面的一种实施方式中，所述获取第二OpenId列表之后，所述方法还包括：
获取第五OpenId列表，所述第五OpenId列表为所述目标微信公众号中第二未取消关注的用户的OpenId列表；
将所述第五OpenId列表与所述第二OpenId列表进行对比，以得到所述目标微信公众号中第一已取消关注的用户的第六OpenId列表；
更新所述第六OpenId列表中的OpenId对应的用户的关注状态。
在第一方面的一种实施方式中，所述获取第四OpenId列表之后，所述方法还包括：
将所述第四OpenId列表与所述第三OpenId列表按照第二对比规则进行对比，以得到第七OpenId列表，所述第七OpenId列表为所述目标微信公众号第二已取消关注的用户的OpenId列表；
更新所述第七OpenId列表中的OpenId对应的用户的关注状态。
本申请实施例第二方面提供了一种用户数据更新装置，具体包括：
第一同步单元，用于基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
第二同步单元，用于基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；
其中，所述增量同步用于对所述目标微信公众号的新增关注用户的基本信息数据字符串进行同步，所述全量同步用于对所述目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔。
在第二方面的一种实施方式中，所述装置还包括：
存储单元，用于在每次进行所述增量同步后，在用户记录表中保存当前增量同步所确定的关注所述目标微信公众号的用户数量；
判断单元，用于判断进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；
所述判断单元，还用于当进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量超过预定阈值时，触发执行所述全量同步。
在第二方面的一种实施方式中，所述第一同步单元包括：
第一获取子单元，用于获取第一OpenId列表，所述第一OpenId列表为所述目标微信公众号中新增用户的OpenId列表；
所述第一获取子单元，还用于根据所述第一OpenId列表获取所述新增用户的第一用户基本信息数据字符串；
第一转换子单元，用于将所述第一用户基本信息数据字符串转换成第一用户类型对象；
第一处理子单元，用于对所述第一用户类型对象进行处理，并将处理后第一用户类型对象更新至所述目标微信公众号对应的数据库。
在第二方面的一种实施方式中，所述第二同步单元包括：
第二获取子单元，用于获取第二OpenId列表，所述第二OpenId列表为所述目标微信公众号中第一所有用户的OpenId列表，所述第一所有用户的 OpenId列表通过调用所述目标微信公众号的应用程序编程接口API获取；
所述第二获取子单元，还用于根据所述第二OpenId列表获取所述第一所有用户的第二用户基本信息数据字符串；
第二转换子单元，用于将所述第二用户基本信息数据字符串转换为第二用户类型对象；
第二处理单元，用于对所述第二用户类型对象进行处理，并将处理后的第二用户类型对象更新至所述目标微信公众号对应的数据库。
在第二方面的一种实施方式中，所述第一获取子单元具体用于：
获取第三OpenId列表，所述第三OpenId列表为所述目标微信公众号中第二所有用户的OpenId列表，所述第二所有用户的OpenId列表是通过调用所述目标微信公众号的API接口获取；
获取所述第四OpenId列表，所述第四OpenId列表为所述目标微信公众号中第一未取消关注的用户的OpenId列表，所述第一未取消关注的用户的标识列表从所述目标微信公众号对应的数据库中获取；
将所述第三OpenId列表与所述第四OpenId列表按照第一对比规则进行对比，以得到所述第一OpenId列表。
在第二方面的一种实施方式中，所述第二同步单元还包括：
第三获取子单元，用于获取第五OpenId列表，所述第五OpenId列表为所述目标微信公众号中第二未取消关注的用户的OpenId列表；
对比子单元，用于将所述第五OpenId列表与所述第二OpenId列表进行对比，以得到所述目标微信公众号中第一已取消关注的用户的第六OpenId列表；
更新子单元，用于更新所述第六OpenId列表中的OpenId对应的用户的关注状态。
在第二方面的一种实施方式中，所述第一获取子单元还具体用于：
将所述第四OpenId列表与所述第三OpenId列表按照第二对比规则进行对比，以得到第七OpenId列表，所述第七OpenId列表为所述目标微信公众号第二已取消关注的用户的OpenId列表；
更新所述第七OpenId列表中的OpenId对应的用户的关注状态。
本申请实施例第三方面提供了一种处理器，其特征在于，所述处理器用于运行计算机程序，所述计算机程序运行时执行如上述各方面所述用户数据的更新方法的步骤。
本申请实施例第四方面提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时上述各方面所述用户数据的更新方法的步骤。
从以上技术方案可以看出，在对目标微信公众号中的用户的数据进行更新时，基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；其中，所述增量同步用于对所述目标微信公众号中新增用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔。由此可见，本申请通过选择两种不同的时间间隔、并采用两种不同的同步方案对微信公众号的关注用户的数据进行更新，能够让不容易改变、同步耗时较大的数据以较长的时间周期进行同步，同时让变化较为频繁、同步耗时较小的数据以较短的周期进行同步，在让同步更新过程满足实时性要求的前提下，又不会显著增加系统负担、避免同步过程集中执行占用较长的时间。
附图说明
图1为本申请提供的用户数据的更新方法的一个实施例示意图；
图2为本申请提供的用户数据的更新方法的另一实施例示意图；
图3为本申请提供的用户数据更新装置的一个实施例示意图；
图4为本申请提供的用户数据更新装置的另一实施例示意图；
图5为本申请实施例中用户数据更新装置的结构示意图。
具体实施方式
本申请实施例提供了一种用户数据的更新方法及相关设备，用于增加微信公众号更新用户数据的方式，使得更新方式更加丰富。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
参阅图1，图1为本申请提供的用户数据更新方法的一个实施例示意图，包括：
101、基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步。
本实施例中，预先设置第一时间间隔，然后基于该第一时间间隔对目标微信公众号对应的数据库周期性的进行增量同步，其中，增量同步用于对目标微信公众号的新增关注用户的基本信息数据字符串进行同步，也就是说，增量同步只同步目标微信公众号的新增关注用户的基本信息数据字符串。
102、基于第二时间间隔，对目标微信公众号对应的数据库周期性的进行的全量同步。
本实施例中，预先设置第二时间间隔，且所第一时间间隔小于第二时间间隔，基于第二时间间隔，对目标微信公众号对应的数据库周期性的进行全量同步，全量同步用于对目标微信公众号的全部关注用户的基本信息数据字符串进行同步，也就是说，全量同步用于对目标微信公众号中所有用户的基本信息数据字符串进行同步。
需要说明的是，在每次增量同步之后，还可以在在每次进行增量同步后，在用户记录表中保存当前增量同步所确定的关注目标微信公众号的用户数量；判断进行当前增量同步后关注目标微信公众号的用户数量的增加量是否超过预定阈值；若是，则触发执行所述全量同步。举例说明，例如，当前记录表中关注微信公众号的用户数量为1000；如果当前经过增量同步发现，记录表中的用户数达到1500，其与1000的差值大于阈值(例如，预定阈值为 200)，则直接触发全量同步，而不仅仅基于第二时间间隔触发全量同步。
需要说明的是，全量同步的执行过程中，可能因为某个用户的信息无法识别而影响整个同步过程，例如，假设需要对200个用户的数据进行全量同步，如果在对第100个用户进行全量同步时，出现问题，无法识别该用户的信息，将会在问题排除后进行后退，重新从第1个用户开始全量同步，这样就会出现大量的反复工作。而通过上述处理，当关注用户数量明显增加的情况下，能够及时触发全量同步，在因为关注量快速增加而导致全量同步的工作量和处理耗时也会明显增加的情况下，让全量同步的工作适当地分布开，避免在某个时间集中执行全量同步而导致全量同步占用大量时间。
综上所述，在对目标微信公众号中的用户的数据进行更新时，基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；其中，所述增量同步用于对所述目标微信公众号中新增用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔。由此可见，本申请通过选择两种不同的时间间隔对微信公众号中的用户的数据进行更新，能够让不容易改变、同步耗时较大的数据以较长的时间周期进行同步，同时让变化较为频繁、同步耗时较小的数据以较短的周期进行同步，在满足实时性要求的前提下，又不会显著增加系统负担、避免同步过程集中执行占用较长的时间。
请参阅图2，本申请中用户数据的更新方法的另一实施例包括：
201、获取第一OpenId列表。
本实施例中，预先设置两个时间间隔，第一时间间隔以及第二时间间隔，其中，第一时间间隔小于第二时间间隔，例如第一时间间隔为24小时，第二时间间隔为100小时，当目标微信公众号在第一时间间隔运行完成时，可以调用目标微信公众号的“获取用户列表”接口，获取目标微信公众号中的调用目标微信公众号的“获取用户列表”接口时的所有用户的Openid(公众号的普通用户的一个唯一的标识，只针对当前的公众号有效)列表，记为第三 OpenId列表，从目标微信公众号对应的数据库的微信用户表中获取未取消关注的用户的Openid列表，记为第四OpenId列表，且将第三OpenId列表与第四OpenId列表按照第一对比规则进行对比，以得到第一OpenId列表，即从第三OpenId列表中找出在第四OpenId列表中不存在的OpenId，得到新增的 OpenId，即为第一OpenId列表，该第一OpenId列表为目标微信公众号中新增用户的OpenId列表，即为第一OpenId列表。
202、根据第一OpenId列表获取新增用户的第一用户基本信息数据字符串。
本实施例中，用户数据更新装置可以在得到第一OpenId列表之后，根据第一OpenId列表调用微信公众号的“获取用户基本信息”接口，得到新增用户的json格式的用户基本信息数据字符串，即第一用户基本信息数据字符串。
203、将第一用户基本信息数据字符串转换成第一用户类型对象。
本实施例中，用户数据更新装置可以将新增用户的json格式的用户基本信息数据字符串转换成第一用户类型对象，具体转换过程不做限定。
204、对第一用户类型对象进行处理，并将处理后第一用户类型对象更新至目标微信公众号对应的数据库。
本实施例中，用户数据更新装置可以对第一用户类型对象进行处理，具体的可以对用户类型对象中的“昵称、国家、省份、城市、备注”属性进行处理，并将处理后的第一用户类型对象更新至目标微信公众号对应的数据库，具体的处理过程此处不做限定，例如可以通过编程的方式将上述属性对应的值中的“回车符\n”替换成“空字符串”。
需要说明的是，在用户数据更新装置获取第一OpenId列表之后，第四 OpenId列表与第三OpenId列表按照第二对比规则进行对比，以得第七OpenId 列表，即是从第四OpenId列表中找出在第三OpenId列表中不存在的openid，得到已取消关注的OpenId，该第七OpenId列表为目标微信公众号第二已取消关注的用户的OpenId列表；
当确定了第七OpenId列表之后，用户更行装置可以更新第七OpenId列表的标识对应的用户的关注状态，例如将原来的“关注”更新为“取消关注”。
此处不限定更新用户的关注状态过程的时序，可以与目标微信公众号的用户数据更新过程(步骤102至步骤104)同时执行，或者在步骤102至步骤 104之后执行，或者在步骤102至步骤104之前执行。
205、获取第二OpenId列表。
本实施例中，当目标微信公众号在第二时间间隔运行完成是，调用微信公众号的“获取用户列表”接口来获取第二OpenId列表，该第二OpenId列表为目标微信公众号中的第一所有用户的OpenId列表，该第一所有用户为用户处理装置调用目标微信公众号的“获取用户列表”接口获取第二OpenId列表时，该目标微信公众号中的所有用户。
206、根据第二OpenId列表获取第一所有用户的第二用户基本信息数据字符串。
本实施例中，用户数据更新装置可以在得到第二OpenId列表之后，根据第二OpenId列表调用目标微信公众号的“获取用户基本信息”接口，得到第一所有用户的json格式的用户基本信息数据字符串，即第二用户基本信息数据字符串。
207、将所述第二用户基本信息数据字符串转换为第二用户类型对象。
本实施例中，用户数据更新装置可以将第一所有用户的json格式的用户基本信息数据字符串转换成第二用户类型对象，具体转换过程不做限定。
208、对第二用户类型对象进行处理，并将处理后第二用户类型对象更新至目标微信公众号对应的数据库。
需要说明的是，步骤101至步骤104同步目标微信公众号新增用户的数据，即增量同步，步骤105至步骤108同步目标微信公众号所有用户的数据，即全量同步，为了便于区别，可以为增量同步以及全量同步设置不同的触发条件，例如分别部署第一windows任务计划程序以及第二Windows任务计划程序，该第一Windows任务计划程序设置每隔第一时间间隔即触发执行增量同步，该第一时间间隔可以为一天或N小时、或根据需要自行设定，该第二 Windows任务计划程序设置每隔第二时间间隔即触发执行全量同步，该第二时间间隔可以为一周或一个月或根据需要自行设定，具体不做限定。
需要说明的是，触发全量同步的方式，在每次进行增量同步后，在用户记录表中保存当前增量同步所确定的关注目标微信公众号的用户数量，并判断进行当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；当进行当前增量同步后关注所述目标微信公众号的用户数量的增加量超过预定阈值时，则触发执行所述全量同步。当然，只是以上述为例进行说明如何触发增量同步以及如何触发全量同步，也可以有其他的方式，具体不做限定。
本实施例中，用户数据更新装置可以对第二用户类型对象进行处理，具体的可以对用户类型对象中的“昵称、国家、省份、城市、备注”等属性进行处理，并将处理后的第二用户类型对象更新至目标微信公众号对应的数据库，具体的处理过程此处不做限定，例如可以通过编程的方式将上述属性对应的值中的“回车符\n”替换成“空字符串”。
需要说明的是，在获取第二OpenId列表之后，用户数据更新装置还可以获取第五OpenId列表，该第五OpenId列表为调用目标微信公众号的“获取用户列表”接口获取第五OpenId列表时，目标微信公众号中未取消关注的用户的OpenId列表；
用户数据更新装置可以将第五OpenId列表与第二OpenId列表进行对比，以得到目标微信公众号中第一已取消关注的用户的第六OpenId列表，该第六 OpenId列表为目标微信公众号中当前已取消关注的用户的OpenId列表；
当确定了第六OpenId列表之后，用户更新装置可以更新第六OpenId列表的标识对应的用户的关注状态，例如将原来的“关注”更新为“取消关注”。
此处不限定更新用户的关注状态过程的时序，可以与目标微信公众号的用户数据更新过程(步骤206至步骤208)同时执行，或者在步骤206至步骤 208之后执行，或者在步骤206至步骤208之前执行。
综上所述，本申请通过选择两种不同的时间间隔对微信公众号中的用户的数据进行更新，能够让不容易改变、同步耗时较大的数据以较长的时间周期进行同步，同时让变化较为频繁、同步耗时较小的数据以较短的周期进行同步，在满足实时性要求的前提下，又不会显著增加系统负担、避免同步过程集中执行占用较长的时间。
上面从用户数据的更新方法的角度对本申请实施例进行说明，下面从用户数据更新装置的角度对本申请实施例进行说明。
请参阅图3，本申请实施例中用户数据更行装置的实施例包括：
第一同步单元301，用于基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
第二同步单元302，用于基于第二时间间隔，对目标微信公众号对应的数据库周期性的进行的全量同步；
其中，增量同步用于对目标微信公众号的新增关注用户的基本信息数据字符串进行同步，全量同步用于对目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且第一时间间隔小于第二时间间隔。
为了便于理解，下面结合图4对本申请实施例进行详细秒速。
参阅图4，图4为本申请中用于数据更新装置的另一实施例示意图，包括：
第一同步单元401，用于基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
第二同步单元404 ，用于基于第二时间间隔，对目标微信公众号对应的数据库周期性的进行的全量同步；其中，增量同步用于对目标微信公众号的新增关注用户的基本信息数据字符串进行同步，全量同步用于对目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且第一时间间隔小于第二时间间隔；
存储单元402 ，用于在每次进行所述增量同步后，在用户记录表中保存当前增量同步所确定的关注所述目标微信公众号的用户数量；
判断单元403 ，用于判断进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；
所述判断单元403 ，还用于当进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量超过预定阈值时，触发执行所述全量同步。
其中，第一同步单元401可以进一步包括：
第一获取子单元4011，用于获取第一OpenId列表，第一OpenId列表为目标微信公众号中新增用户的OpenId列表；
第一获取子单元4011，还用于根据第一OpenId列表获取新增用户的第一用户基本信息数据字符串；
第一转换子单元4012，用于将第一用户基本信息数据字符串转换成第一用户类型对象；
第一处理子单元4013，用于对第一用户类型对象进行处理，并将处理后第一用户类型对象更新至目标微信公众号对应的数据库。
第二同步单元404可以进一步包括：
第二获取子单元4041，用于获取第二OpenId列表，第二OpenId列表为目标微信公众号中第一所有用户的OpenId列表，第一所有用户的OpenId列表通过调用目标微信公众号的应用程序编程接口API获取；
第二获取子单元4041，还用于根据第二OpenId列表获取第一所有用户的第二用户基本信息数据字符串；
第二转换子单元4042，用于将第二用户基本信息数据字符串转换为第二用户类型对象；
第二处理单元4043，用于对第二用户类型对象进行处理，并将处理后的第二用户类型对象更新至目标微信公众号对应的数据库；
第三获取子单元4044，用于获取第五OpenId列表，第五OpenId列表为目标微信公众号中第二未取消关注的用户的OpenId列表；
对比子单元4045，用于将第五OpenId列表与第二OpenId列表进行对比，以得到目标微信公众号中第一已取消关注的用户的第六OpenId列表；
更新子单元4046，用于更新第六OpenId列表中的OpenId对应的用户的关注状态；
其中，第一获取子单元4011具体用于：
获取第三OpenId列表，第三OpenId列表为目标微信公众号中第二所有用户的OpenId列表，第二所有用户的OpenId列表是通过调用目标微信公众号的API接口获取；
获取所述第四OpenId列表，第四OpenId列表为目标微信公众号中第一未取消关注的用户的OpenId列表，第一未取消关注的用户的标识列表从目标微信公众号对应的数据库中获取；
将第三OpenId列表与第四OpenId列表按照第一对比规则进行对比，以得到第一OpenId列表。
第一获取子单元4011还具体用于：
将第四OpenId列表与第三OpenId列表按照第二对比规则进行对比，以得到第七OpenId列表，所述第七OpenId列表为目标微信公众号第二已取消关注的用户的OpenId列表；
更新第七OpenId列表中的OpenId对应的用户的关注状态。
本实施例中的用户数据更新装置的各单元之间的交互方式如前述图2所示实施例中的描述，具体此处不再赘述。
综上所述，本申请通过选择两种不同的时间间隔对微信公众号中的用户的数据进行更新，能够让不容易改变、同步耗时较大的数据以较长的时间周期进行同步，同时让变化较为频繁、同步耗时较小的数据以较短的周期进行同步，在满足实时性要求的前提下，又不会显著增加系统负担、避免同步过程集中执行占用较长的时间。
请参阅图5，本申请实施例还提供了一种用户数据更新装置，所述用户数据更新装置包括处理器501和存储器502，上述获取单元、转换单元和处理单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。
处理器501中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来对用户数据进行更新。
存储器502可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。
本申请实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现所述用户数据的更新方法。
本申请实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行所述用户数据的更新方法。
本申请实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：
基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；
其中，所述增量同步用于对所述目标微信公众号的新增关注用户的基本信息数据字符串进行同步，所述全量同步用于对所述目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔。
可选地，所述对目标微信公众号对应的数据库周期性的进行增量同步之后，所述方法还包括：
在每次进行所述增量同步后，在用户记录表中保存当前增量同步所确定的关注所述目标微信公众号的用户数量；
判断进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；
若是，则触发执行所述全量同步。
可选地，所述对目标微信公众号对应的数据库周期性的进行增量同步包括：
获取第一OpenId列表，所述第一OpenId列表为所述目标微信公众号中新增用户的OpenId列表；
根据所述第一OpenId列表获取所述新增用户的第一用户基本信息数据字符串；
将所述第一用户基本信息数据字符串转换成第一用户类型对象；
对所述第一用户类型对象进行处理，并将处理后第一用户类型对象更新至所述目标微信公众号对应的数据库。
可选地，所述对所述目标微信公众号对应的数据库周期性的进行的全量同步包括：
获取第二OpenId列表，所述第二OpenId列表为所述目标微信公众号中第一所有用户的OpenId列表，所述第一所有用户的OpenId列表通过调用所述目标微信公众号的应用程序编程接口API获取；
根据所述第二OpenId列表获取所述第一所有用户的第二用户基本信息数据字符串；
将所述第二用户基本信息数据字符串转换为第二用户类型对象；
对所述第二用户类型对象进行处理，并将处理后的第二用户类型对象更新至所述目标微信公众号对应的数据库。
可选地，所述获取第一OpenId列表包括：
获取第三OpenId列表，所述第三OpenId列表为所述目标微信公众号中第二所有用户的OpenId列表，所述第二所有用户的OpenId列表是通过调用所述目标微信公众号的API接口获取；
获取所述第四OpenId列表，所述第四OpenId列表为所述目标微信公众号中第一未取消关注的用户的OpenId列表，所述第一未取消关注的用户的标识列表从所述目标微信公众号对应的数据库中获取；
将所述第三OpenId列表与所述第四OpenId列表按照第一对比规则进行对比，以得到所述第一OpenId列表。
可选地，所述获取第二OpenId列表之后，所述方法还包括：
获取第五OpenId列表，所述第五OpenId列表为所述目标微信公众号中第二未取消关注的用户的OpenId列表；
将所述第五OpenId列表与所述第二OpenId列表进行对比，以得到所述目标微信公众号中第一已取消关注的用户的第六OpenId列表；
更新所述第六OpenId列表中的OpenId对应的用户的关注状态。
可选地，所述获取第四OpenId列表之后，所述方法还包括：
将所述第四OpenId列表与所述第三OpenId列表按照第二对比规则进行对比，以得到第七OpenId列表，所述第七OpenId列表为所述目标微信公众号第二已取消关注的用户的OpenId列表；
更新所述第七OpenId列表中的OpenId对应的用户的关注状态。
本文中的设备可以是服务器、PC、PAD、手机等。
本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：
基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；
其中，所述增量同步用于对所述目标微信公众号的新增关注用户的基本信息数据字符串进行同步，所述全量同步用于对所述目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔。
可选地，所述对目标微信公众号对应的数据库周期性的进行增量同步之后，所述方法还包括：
在每次进行所述增量同步后，在用户记录表中保存当前增量同步所确定的关注所述目标微信公众号的用户数量；
判断进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；
若是，则触发执行所述全量同步。
可选地，所述对目标微信公众号对应的数据库周期性的进行增量同步包括：
获取第一OpenId列表，所述第一OpenId列表为所述目标微信公众号中新增用户的OpenId列表；
根据所述第一OpenId列表获取所述新增用户的第一用户基本信息数据字符串；
将所述第一用户基本信息数据字符串转换成第一用户类型对象；
对所述第一用户类型对象进行处理，并将处理后第一用户类型对象更新至所述目标微信公众号对应的数据库。
可选地，所述对所述目标微信公众号对应的数据库周期性的进行的全量同步包括：
获取第二OpenId列表，所述第二OpenId列表为所述目标微信公众号中第一所有用户的OpenId列表，所述第一所有用户的OpenId列表通过调用所述目标微信公众号的应用程序编程接口API获取；
根据所述第二OpenId列表获取所述第一所有用户的第二用户基本信息数据字符串；
将所述第二用户基本信息数据字符串转换为第二用户类型对象；
对所述第二用户类型对象进行处理，并将处理后的第二用户类型对象更新至所述目标微信公众号对应的数据库。
可选地，所述获取第一OpenId列表包括：
获取第三OpenId列表，所述第三OpenId列表为所述目标微信公众号中第二所有用户的OpenId列表，所述第二所有用户的OpenId列表是通过调用所述目标微信公众号的API接口获取；
获取所述第四OpenId列表，所述第四OpenId列表为所述目标微信公众号中第一未取消关注的用户的OpenId列表，所述第一未取消关注的用户的标识列表从所述目标微信公众号对应的数据库中获取；
将所述第三OpenId列表与所述第四OpenId列表按照第一对比规则进行对比，以得到所述第一OpenId列表。
可选地，所述获取第二OpenId列表之后，所述方法还包括：
获取第五OpenId列表，所述第五OpenId列表为所述目标微信公众号中第二未取消关注的用户的OpenId列表；
将所述第五OpenId列表与所述第二OpenId列表进行对比，以得到所述目标微信公众号中第一已取消关注的用户的第六OpenId列表；
更新所述第六OpenId列表中的OpenId对应的用户的关注状态。
可选地，所述获取第四OpenId列表之后，所述方法还包括：
将所述第四OpenId列表与所述第三OpenId列表按照第二对比规则进行对比，以得到第七OpenId列表，所述第七OpenId列表为所述目标微信公众号第二已取消关注的用户的OpenId列表；
更新所述第七OpenId列表中的OpenId对应的用户的关注状态。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (7)

1.一种用户数据的更新方法，其特征在于，包括：
基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行全量同步；
其中，所述增量同步用于对所述目标微信公众号的新增关注用户的基本信息数据字符串进行同步，所述全量同步用于对所述目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔；
所述对目标微信公众号对应的数据库周期性的进行增量同步包括：
获取第一OpenId列表，所述第一OpenId列表为所述目标微信公众号中新增用户的OpenId列表；
根据所述第一OpenId列表获取所述新增用户的第一用户基本信息数据字符串；
将所述第一用户基本信息数据字符串转换成第一用户类型对象；
对所述第一用户类型对象进行处理，并将处理后第一用户类型对象更新至所述目标微信公众号对应的数据库；
所述获取第一OpenId列表包括：
获取第三OpenId列表，所述第三OpenId列表为所述目标微信公众号中第二所有用户的OpenId列表，所述第二所有用户的OpenId列表是通过调用所述目标微信公众号的API接口获取；
获取第四OpenId列表，所述第四OpenId列表为所述目标微信公众号中第一未取消关注的用户的OpenId列表，所述第一未取消关注的用户的标识列表从所述目标微信公众号对应的数据库中获取；
将所述第三OpenId列表与所述第四OpenId列表按照第一对比规则进行对比，以得到所述第一OpenId列表。
2.根据权利要求1所述的方法，其特征在于，所述对目标微信公众号对应的数据库周期性的进行增量同步之后，所述方法还包括：
在每次进行所述增量同步后，在用户记录表中保存当前增量同步所确定的关注所述目标微信公众号的用户数量；
判断进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；
若是，则触发执行所述全量同步。
3.根据权利要求1或2所述的方法，其特征在于，所述对所述目标微信公众号对应的数据库周期性的进行的全量同步包括：
获取第二OpenId列表，所述第二OpenId列表为所述目标微信公众号中第一所有用户的OpenId列表，所述第一所有用户的OpenId列表通过调用所述目标微信公众号的应用程序编程接口API获取；
根据所述第二OpenId列表获取所述第一所有用户的第二用户基本信息数据字符串；
将所述第二用户基本信息数据字符串转换为第二用户类型对象；
对所述第二用户类型对象进行处理，并将处理后的第二用户类型对象更新至所述目标微信公众号对应的数据库。
4.一种用户数据的更新装置，其特征在于，包括：
第一同步单元，用于基于第一时间间隔，对目标微信公众号对应的数据库周期性的进行增量同步；
第二同步单元，用于基于第二时间间隔，对所述目标微信公众号对应的数据库周期性的进行的全量同步；
其中，所述增量同步用于对所述目标微信公众号的新增关注用户的基本信息数据字符串进行同步，所述全量同步用于对所述目标微信公众号的全部关注用户的基本信息数据字符串进行同步，并且所述第一时间间隔小于所述第二时间间隔；
所述第一同步单元包括：
第一获取子单元，用于获取第一OpenId列表，所述第一OpenId列表为所述目标微信公众号中新增用户的OpenId列表；
所述第一获取子单元，还用于根据所述第一OpenId列表获取所述新增用户的第一用户基本信息数据字符串；
第一转换子单元，用于将所述第一用户基本信息数据字符串转换成第一用户类型对象；
第一处理子单元，用于对所述第一用户类型对象进行处理，并将处理后第一用户类型对象更新至所述目标微信公众号对应的数据库；
所述第一获取子单元具体用于：
获取第三OpenId列表，所述第三OpenId列表为所述目标微信公众号中第二所有用户的OpenId列表，所述第二所有用户的OpenId列表是通过调用所述目标微信公众号的API接口获取；
获取第四OpenId列表，所述第四OpenId列表为所述目标微信公众号中第一未取消关注的用户的OpenId列表，所述第一未取消关注的用户的标识列表从所述目标微信公众号对应的数据库中获取；
将所述第三OpenId列表与所述第四OpenId列表按照第一对比规则进行对比，以得到所述第一OpenId列表。
5.根据权利要求4所述的装置，其特征在于，所述装置还包括：
存储单元，用于在每次进行所述增量同步后，在用户记录表中保存当前增量同步所确定的关注所述目标微信公众号的用户数量；
判断单元，用于判断进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量是否超过预定阈值；
所述判断单元，还用于当进行所述当前增量同步后关注所述目标微信公众号的用户数量的增加量超过预定阈值时，触发执行所述全量同步。
6.一种处理器，其特征在于，所述处理器用于运行计算机程序，所述计算机程序运行时执行如权利要求1至3中任意一项所述方法。
7.一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现如权利要求1至3中任意一项所述方法的步骤。
CN201710895754.1A 2017-09-27 2017-09-27 一种用户数据的更新方法及相关设备 Active CN110019260B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710895754.1A CN110019260B (zh) 2017-09-27 2017-09-27 一种用户数据的更新方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710895754.1A CN110019260B (zh) 2017-09-27 2017-09-27 一种用户数据的更新方法及相关设备

Publications (2)

Publication Number Publication Date
CN110019260A CN110019260A (zh) 2019-07-16
CN110019260B true CN110019260B (zh) 2021-10-08

Family

ID=67186377

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710895754.1A Active CN110019260B (zh) 2017-09-27 2017-09-27 一种用户数据的更新方法及相关设备

Country Status (1)

Country Link
CN (1) CN110019260B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110807885A (zh) * 2019-11-13 2020-02-18 普联技术有限公司 一种基于微信的报警方法及报警设备
CN111107182B (zh) * 2019-12-31 2022-09-20 瑞斯康达科技发展股份有限公司 一种mac地址同步方法、装置、系统、设备及介质
CN115361351A (zh) * 2022-07-21 2022-11-18 中国电信股份有限公司 数据更新方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104615453A (zh) * 2014-09-26 2015-05-13 腾讯科技（深圳）有限公司 一种地图数据处理方法、装置及系统
CN104980519A (zh) * 2015-06-29 2015-10-14 北京奇虎科技有限公司 多机房存储系统
CN105243086A (zh) * 2015-09-08 2016-01-13 北京北大千方科技有限公司 一种车辆信息查询方法和装置
CN106156164A (zh) * 2015-04-15 2016-11-23 腾讯科技（深圳）有限公司 资源信息处理方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8161234B2 (en) * 2008-12-30 2012-04-17 Intel Corporation Dynamically switching command types to a mass storage drive

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104615453A (zh) * 2014-09-26 2015-05-13 腾讯科技（深圳）有限公司 一种地图数据处理方法、装置及系统
CN106156164A (zh) * 2015-04-15 2016-11-23 腾讯科技（深圳）有限公司 资源信息处理方法和装置
CN104980519A (zh) * 2015-06-29 2015-10-14 北京奇虎科技有限公司 多机房存储系统
CN105243086A (zh) * 2015-09-08 2016-01-13 北京北大千方科技有限公司 一种车辆信息查询方法和装置

Also Published As

Publication number Publication date
CN110019260A (zh) 2019-07-16

Similar Documents

Publication Publication Date Title
CN106202235B (zh) 一种数据处理方法及装置
CN106547578B (zh) 终端应用app的加载方法及装置
RU2488166C2 (ru) Ориентируемая на обслуживание архитектура, основанная на конвейере
US9836346B2 (en) Error troubleshooting using a correlated knowledge base
CN107066519B (zh) 一种任务检测方法及装置
CN110019260B (zh) 一种用户数据的更新方法及相关设备
CN110008018A (zh) 一种批量任务处理方法、装置及设备
CN103927314B (zh) 一种数据批量处理的方法和装置
CN106681581B (zh) 应用程序图标排列方法和装置
CN104113576A (zh) 一种客户端的更新方法及装置
US9875137B2 (en) Intelligent application back stack management
JP2019512126A (ja) 機械学習システムをトレーニングする方法及びシステム
CN106886545B (zh) 页面展示方法、页面资源的缓存方法及装置
CN104536819A (zh) 基于web服务的任务调度方法
US11323389B2 (en) Logic scaling sets for cloud-like elasticity of legacy enterprise applications
CN113408254A (zh) 一种页面表单信息填写方法、装置、设备和可读介质
CN110381150B (zh) 区块链上的数据处理方法、装置、电子设备及存储介质
JP2019509567A (ja) アプリケーション（ａｐｐ）のためのリソースロード方法、サービス機能実施方法及び装置
CN110688383A (zh) 数据采集方法及系统
CN109783159A (zh) 基于配置信息的应用启动方法和装置
CN105320523B (zh) 一种数据处理方法和装置
CN109039695B (zh) 业务故障处理方法、装置及设备
CN111078418A (zh) 操作同步方法、装置、电子设备及计算机可读存储介质
CN108133123B (zh) 一种应用程序的识别方法及系统
CN107562533B (zh) 一种数据加载处理方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: 100080 No. 401, 4th Floor, Haitai Building, 229 North Fourth Ring Road, Haidian District, Beijing

Applicant after: Beijing Guoshuang Technology Co.,Ltd.

Address before: 100086 Beijing city Haidian District Shuangyushu Area No. 76 Zhichun Road cuigongfandian 8 layer A

Applicant before: Beijing Guoshuang Technology Co.,Ltd.

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant