一种用户信息的管理方法和系统

技术领域

本公开涉及数据管理技术领域，特别涉及一种用户信息的管理方法和系统。

背景技术

数据是游戏的支撑，数据存储是游戏中非常重要的一部分。一方面可以为玩家提供持续的可积累的游戏体验，另一方面也可以为分析和改进游戏的设计提供重要的参考；目前的常见的数据存储方式可以分为集群模式和非集群模式，两种方式都各有优缺点；

1)非集群模式，也即单机模式，是把所有的数据都存储于单一的数据库服务器中，其优点是设计简单，并且维护成本比较低；缺点是难以支持大数据量的存储和访问，与不支持动态的数据扩容；适用于比较小规模数据量的场景。

2)集群模式,也即多服务器模式，将大量的数据分散到多台数据库服务器中，用于支撑大量数据的存储和访问。其优点是可以满足大量的数据存储和访问，也能支持业务的动态数据增长；缺点是设计相对复杂，维护成本也相对较高；适用于大数据量或者是未来可预见的大数量增长的场景。

随着计算机技术的不断发展和数据量的不断增大，业内在进行数据存储时通常均使用集群模式进行。区别于单机的方式，基于集群的方式通常需要对待存储的数据进行划分，使其分别存储在不同的数据库服务器中来实现比较均衡和高效的存储和访问。一般来说，常见的方式是采用全局唯一的用户ID作为存储和访问的依据，例如通过雪花算法、数据库自增唯一ID等来生成全局用户ID，然后通过取模或者哈希的方式将用户ID映射至不同的数据库服务器中，但是在这种情况下，若数据库服务器的数量发生变化，例如新增数据库服务器时，进行取模或者哈希运算时用户ID与数据库服务器之间的映射关系会发生变化，导致原有映射关系错乱，按照原有映射关系新增的用户无法存储至新增的数据库服务器中，而对映射关系进行调整则会导致原有数据在访问时出现基于映射得到的数据库与原有存储的数据库不同，进而无法实现相应数据信息的调用。

发明内容

本公开实施例的目的在于提供一种用户信息的管理方法和系统，用以解决现有技术中在数据库服务器发生变化时导致的映射关系错乱的问题。

本公开的实施例采用如下技术方案：一种用户信息的管理方法，包括：在所有集群中确定第一集群作为当前用户的归属集群；在所述第一集群中确定第一数据表以存储所述当前用户的用户信息；为所述当前用户分配全局ID，并基于所述第一集群的集群ID、第一数据表的数据表ID以及所述全局ID确定所述当前用户的用户ID；将所述用户ID作为所述当前用户的关键字存储至所述第一数据表中。

进一步，所述在所有集群中确定第一集群作为当前用户的归属集群，包括：按照以下方式之一确定所述第一集群：在所有集群中随机选择一个集群作为所述第一集群；在所有集群中选择使用率最低的集群作为所述第一集群；在所有集群中选择当前指定集群作为所述第一集群，其中，所述当前指定集群每隔第一预设周期进行一次切换；基于用户的网络归属信息，在所有集群中确定所述网络归属信息对应的集群为所述第一集群。

进一步，所述在所述第一集群中确定第一数据表以存储所述当前用户的用户信息，包括：按照以下方式之一确定所述第一数据表：在所述第一集群的所有数据表中随机选择一个数据表作为第一数据表；在所述第一集群的所有数据表中选择使用率最低的数据表作为第一数据表；按照预定顺序在所述第一集群的所有数据表中选择一个数据表作为第一数据表。

进一步，还包括：基于当前用户的用户ID，确定所述当前用户所归属的集群以及保存所述当前用户的用户信息的数据表；在所述数据表中基于所述用户ID确定所述当前用户的用户信息。

进一步，所述用户ID的格式为：第一位数的集群ID、第二位数的数据表ID以及第三位数的全局ID。

本公开的实施例还提供了一种用户信息的管理系统，包括：逻辑服务器，用于根据上述的管理方法对用户信息进行管理；至少一个集群，每个所述集群中至少包括预设数量的数据表，每个数据表均用于存储用户的用户信息，其中，所述集群通过多个数据库服务器组成。

进一步，所述逻辑服务器，还用于：基于当前用户的用户ID，确定所述当前用户所归属的集群以及保存所述当前用户的用户信息的数据表；在所述数据表中基于所述用户ID确定所述当前用户的用户信息。

进一步，每个所述集群至少包括主数据库和从数据库，所述主数据库和所述从数据库内均包含有所述预设数量的数据表，所述主数据库内的每个所述数据表在所述从数据库内均存在一个对应的数据表。

进一步，所述逻辑服务器通过所述主数据库进行所述用户信息的存储，通过所述从数据库进行所述用户信息的查询。

进一步，每间隔第二预设周期，所述主数据库与所述从数据库之间进行一次数据同步。

本公开实施例的有益效果在于：通过调整用户ID的生成方式，将用户ID与对应的集群和数据表进行关联，使用户ID与相应集群和数据表之间的映射关系不会根据集群数量的调整发生改变，避免出现数据信息调用失败的问题。

附图说明

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本公开第一实施例中用户信息的管理方法的流程图；

图2为本公开第二实施例中用户信息的管理系统的架构示意图。

具体实施方式

此处参考附图描述本公开的各种方案以及特征。

应理解的是，可以对此处申请的实施例做出各种修改。因此，上述说明书不应该视为限制，而仅是作为实施例的范例。本领域的技术人员将想到在本公开的范围和精神内的其他修改。

包含在说明书中并构成说明书的一部分的附图示出了本公开的实施例，并且与上面给出的对本公开的大致描述以及下面给出的对实施例的详细描述一起用于解释本公开的原理。

通过下面参照附图对给定为非限制性实例的实施例的优选形式的描述，本公开的这些和其它特性将会变得显而易见。

还应当理解，尽管已经参照一些具体实例对本公开进行了描述，但本领域技术人员能够确定地实现本公开的很多其它等效形式，它们具有如权利要求的特征并因此都位于借此所限定的保护范围内。

当结合附图时，鉴于以下详细说明，本公开的上述和其他方面、特征和优势将变得更为显而易见。

此后参照附图描述本公开的具体实施例；然而，应当理解，所申请的实施例仅仅是本公开的实例，其可采用多种方式实施。熟知和/或重复的功能和结构并未详细描述以避免不必要或多余的细节使得本公开模糊不清。因此，本文所申请的具体的结构性和功能性细节并非意在限定，而是仅仅作为权利要求的基础和代表性基础用于教导本领域技术人员以实质上任意合适的详细结构多样地使用本公开。

本说明书可使用词组“在一种实施例中”、“在另一个实施例中”、“在又一实施例中”或“在其他实施例中”，其均可指代根据本公开的相同或不同实施例中的一个或多个。

为了解决现有技术中存在的问题，本公开的第一实施例提供了一种用户信息的管理方法，该方法适用于对大数据量的用户进行ID分配和相应用户信息的管理，其流程图如图1所示，主要公开了步骤S101至S104：

S101，在所有集群中确定第一集群作为当前用户的归属集群。

本实施例中，集群主要指由一个或多个数据库服务器组成用于存储用户数据的数据库集群。针对一个具有大量用户参与使用的应用或者游戏来说，其用于维护用户数据的数据库集群通常具有至少一个，每个集群均有全局唯一的集群ID，并且随着应用或游戏的长时间运行导致的用户增长，数据库集群的数量也会进行相应调整。

在新用户注册时，需要为该用户分配全局唯一的用户ID，并且该用户的所有用户信息(例如个人信息、设置信息、游戏存档等)均与用户ID关联，并需要通过该用户ID在集群中进行查询和调取。因此，在新用户注册时，需要首先为该用户分配其归属的集群，从所有集群中确定一个第一集群作为当前用户的归属集群即可，第一集群可以是所有集群中的任意一个集群。

具体地，可以通过以下任意一种方式在所有集群中确定第一集群：

(1)在所有集群中随机选择一个集群作为第一集群；

每当有一个新用户进行注册时，在所有集群中随机选择一个集群作为该新用户的归属集群(即第一集群)即可，在通常情况下，使用随机分配的方式可以基本保证所有集群内所保存的用户数量持平。

(2)在所有集群中选择使用率最低的集群作为第一集群；

使用率是指当前集群中所保存的用户数量在该集群能保存的最大用户数量之中所占的比例，使用率越高，说明集群内保存的用户数量越多，为了实现用户数量平均，可以在新用户注册时将当前使用率最低的集群(即当前保存用户数量最少的集群)作为第一集群。

(3)在所有集群中选择当前指定集群作为第一集群，其中，当前指定集群每隔第一预设周期进行一次切换；

在游戏或者应用实际运行时，可在所有集群中指定一个集群作为某个时间段内注册的所有新用户归属的集群，并且指定集群间隔第一预设周期之后进行切换，例如，第一预设周期为一周，在一月的第一周内，指定的集群为集群A，则所有在一月的第一周内注册的新用户所归属的集群均为集群A，在一月的第二周将指定集群切换为集群B，则在一月的第二周内注册的所有新用户所归属的集群均为集群B，以此类推。

(4)基于用户的网络归属信息，在所有集群中确定网络归属信息对应的集群为第一集群。

本实施例中的网络归属信息可以为用户所使用网络的运营商，或者用户当前所在地。不同的网络运营商对应不同的集群，例如移动用户对应集群A，联通用户对应集群B，电信用户对应集群C，其他用户对应集群D，在进行第一集群的确定时，基于当前用户的运营商确定对应集群作为第一集群即可；或者，东北地区和华北地区用户对应集群A，华中地区和华南地区用户对应集群B，西北地区和西南地区用户对应集群C，在进行第一集群的确定时，基于当前用户的所在地确定对应集群作为第一集群即可。

需要注意的是，本实施例中所公开的几种确定第一集群的方式只是在实际使用过程中可能存在的几种优选实施方式，上述几种方式可以根据实际需求进行切换，维护人员也可以根据实际情况使用其他分配集群的方式，本实施例在此不进行限定。

S102，在第一集群中确定第一数据表以存储当前用户的用户信息。

本实施例中每个数据库集群均以数据表的形式进行用户信息的存储，并且，单个集群中的数据表通过水平拆分成多个数据表以减少每个数据表中的数据条目数，保证在基于用户ID进行相应用户信息获取时，可以减少遍历数据的时间，提升数据查找效率。本实施例中优选将单个集群中的数据表以用户ID为键值进行水平拆分，拆分数量为200拆分后每张表所能保存的数据条目在千万级别，也就是说，单个集群所能保存的用户数量为20亿，基本可以满足大型应用程序或者游戏的使用需求。另外，单个集群内的每张数据表均有一个唯一的数据表ID，不同集群内的数据表可能具有相同的数据表ID。

在新用户注册时，首先确定其归属的集群，然后在该集群中选择第一数据表用以存储该用户的用户信息，第一数据表可以是第一集群中的任意一张数据表，其可以通过以下任意一种方式在第一集群中确定：

(1)在第一集群的所有数据表中随机选择一个数据表作为第一数据表；

每当有一个新用户进行注册并分配到第一集群时，在第一集群内随机选择一个数据表作为第一数据表即可，在通常情况下，使用随机分配的方式可以基本保证第一集群内所有数据表所保存的用户数量持平。

(2)在第一集群的所有数据表中选择使用率最低的数据表作为第一数据表；

此处使用率是指当前数据表中所保存的用户数量在该数据表能保存的最大用户数量之中所占的比例，使用率越高，说明数据表内保存的用户数量越多，为了实现用户数量平均，可以在新用户注册时将当前使用率最低的数据表(即当前保存用户数量最少的数据表)作为第一数据表。

(3)按照预定顺序在第一集群的所有数据表中选择一个数据表作为第一数据表。

预定顺序可以按照数据表的数量或者实际需求进行调整，例如在确定当前用户的第一数据表时，首先获取当前用户的上一个用户在注册时所对应被存储至的数据表ID，并在上一个数据表ID的基础上进行加1操作，此时得到的数据表ID所对应的数据表即为第一数据表。

需要注意的是，本实施例中所公开的几种确定第一数据表的方式只是在实际使用过程中可能存在的几种优选实施方式，上述几种方式可以根据实际需求进行切换，维护人员也可以根据实际情况使用其他分配数据表的方式，本实施例在此不进行限定。

S103，为当前用户分配全局ID，并基于第一集群的集群ID、第一数据表的数据表ID以及全局ID确定当前用户的用户ID。

全局ID是指当前应用或游戏内所有集群内存储的用户所具有的唯一的ID，任意一个用户的全局ID不与当前应用或游戏内的其他用户具有相同的全局ID，进而实现用户之间的进一步区分，在有新用户注册时，可在上一个注册用户的全局ID的基础上进行加1操作以实现当前用户的全局ID的确定，或者使用其他方式进行全局ID的分配，本实施例不进行限制。在全局ID确定之后，基于当前用户被分配的第一集群的集群ID、所在第一数据表的数据表ID以及全局ID，生成该用户的用户ID。具体地，生成的用户ID具体可以由第一位数的集群ID、第二位数的数据表ID以及第三位数的全局ID构成，其中，第一位数、第二位数以及第三位数的具体值可以根据集群数量、数据表数量以及预估的用户数量进行确定，例如，本实施例中可以优选设置用户ID为64比特的无符号的字符串(通常为数字形式)，其中，集群ID为8比特、数据表ID为16比特，剩余40比特为全局ID。

S104，将用户ID作为当前用户的关键字存储至第一数据表中。

在确定用户ID后，将其作为当前用户的关键字(key)并存储至第一数据表中，而该用户在运行应用或游戏的过程中所产生的所有用户信息以及相关数据，均作为该关键字对应的值(value)存储在第一数据表中。

在应用或游戏实际运行过程中，新用户在注册时通常会设置个性化的用户名以及密码，在注册过程中与后台生成的用户ID进行关联，当用户登录之后，用户所进行的个人设置、运行记录等内容均作为用户信息存储在相应的第一数据表中。当用户进行登录操作或者执行用户信息的查询操作时，首先基于自身用户ID中的集群ID确定其所归属的集群，然后在该集群中通过数据表ID确定保存有对应用户信息的数据表，最后以用户ID为查询条件在数据表中遍历所有数据条目，查找并获取该用户ID对应的用户信息。

本实施例通过调整用户ID的生成方式，将用户ID与对应的集群和数据表进行关联，即便集群数量出现调整，当前已有用户与其对应集群和数据表之间的映射关系也不会发生变化，也就不会出现因映射关系调整而导致的数据访问失败等情况出现。与此同时，当需要新增集群时，不需要调整任何用户ID生成逻辑，也不需要进行数据迁移，在生成新用户的用户ID时将其对应的集群配置为新增加的集群即可，降低了集群维护和数据迁移成本，同时避免了停服维护或中断等操作，保证产品的长期稳定运行，为用户带来更好的使用体验。

本公开的第二实施例提供了一种用户信息的管理系统，其可以作为应用或者游戏的后台服务器使用，主要用于实现用户信息的管理，在运行过程中为新用户进行用户ID分配，用户信息存储、查询或读取等操作。图2示出了用户信息的管理系统的架构示意图，其主要包括逻辑服务器10和至少一个集群20，其中，集群20通过多个数据库服务器组成。

逻辑服务器10主要通过本公开第一实施例中的用户信息管理方法对用户信息进行管理，其具体所实现的操作或执行原理已在第一实施例中进行了详细描述，本实施例在此不再重复赘述，另外，逻辑服务器10的数量也不限于1个，图2即示出了具有两个逻辑服务器10的情况，只要保证每个逻辑服务器10均与每个集群20连接即可。逻辑服务器10在新用户注册时按照第一实施例所公开的用户ID的生成方式为新用户配置归属集群和数据表；在进行用户信息查询时则基于用户的用户ID，在确定当前用户所归属的集群以及保存当前用户的用户信息的数据表之后，在数据表中基于用户ID确定当前用户的用户信息即可。

集群20通过多个数据库服务器组成，其数量可根据实际情况进行设定，并且可以在后期运行中进行新增，图2中只示出了具有2个集群的情况。每个集群20均具有一个独立的集群ID，并且每个集群20中至少包括预设数量的数据表30，并主要通过数据表30进行用户信息的存储。

进一步地，每一个集群20至少包括一个主数据库201和一个从数据库202，从数据库202实际上是主数据库201的备份，主数据库201和从数据库202内所包含的数据表的数量相同，并且主数据库201内的每个数据表在从数据库202内均存在一个对应且具有相同数据表ID的数据表，二者所存储的用户信息也是相同的。在实际使用时，逻辑服务器10与每个集群10内的主数据库201和从数据库202均连接，主数据库201主要用于实现数据的写入操作，即逻辑服务器10在生成用户ID以及保存用户信息时是将相应数据写入到主数据库201的数据表中；从数据库202主要用于实现数据的读取操作，即逻辑服务器10在获取用户信息时通过查询从数据库202中的数据实现。需要了解的是，为了保证主数据库201和从数据库202之间的数据相同，每个集群20内的主数据库201和从数据库202可以每间隔第二预设周期进行一次数据同步，第二预设周期优选为10毫秒至200毫秒，具体可根据数据新增情况或者数据库性能进行调整。

本实施例通过逻辑服务器10以及集群20的设置，将用户ID与实体集群20进行关联，即便集群数量出现调整，当前已有用户与其对应集群和数据表之间的映射关系也不会发生变化，也就不会出现因映射关系调整而导致的数据访问失败等情况出现。与此同时，集群内通过设置从数据库实现读取操作，降低了主数据库的读取压力，从而整体提升了数据库的性能，降低了数据存储或读取的延迟，优化了实际的使用体验。

以上对本公开多个实施例进行了详细说明，但本公开不限于这些具体的实施例，本领域技术人员在本公开构思的基础上，能够做出多种变型和修改实施例，这些变型和修改都应落入本公开所要求保护的范围之内。