C#生成唯一值的方法

使用1、MaxId表存储各表的MaxId值

 

专门一个数据库，记录各个表的MaxId值，建一个存储过程来取Id，逻辑大致为：开启事物，对于在表中不存在记录，直接返回一个默认值为1的键值，同时插入该条记录到table_key表中。而对于已存在的记录，key值直接在原来的key基础上加1更新到MaxId表中并返回key。

第一步：创建表
create table table_key
(
       table_name   varchar(50) not null primary key,
       key_value    int         not null
)


第二步：创建存储过程来取自增ID
create procedure up_get_table_key
(
   @table_name     varchar(50),
   @key_value      int output
)
as
begin
     begin tran
         declare @key  int
         
         --initialize the key with 1
         set @key=1
         --whether the specified table is exist
         if not exists(select table_name from table_key where table_name=@table_name)
            begin
              insert into table_key values(@table_name,@key)        --default key vlaue:1
            end
         -- step increase
         else    
            begin
                select @key=key_value from table_key with (nolock) where table_name=@table_name
                set @key=@key+1
                --update the key value by table name
                update table_key set key_value=@key where table_name=@table_name
            end
        --set ouput value
    set @key_value=@key

    --commit tran
    commit tran
        if @@error>0
      rollback tran
end

 存储过程中不使用事物，一旦使用到事物性能就急剧下滑。直接使用UPDATE获取到的更新锁，即SQL SERVER会保证UPDATE的顺序执行。（已在用户过千万的并发系统中使用）

create procedure [dbo].[up_get_table_key]
(
   @table_name     varchar(50),
   @key_value      int output
)
as
begin

	SET NOCOUNT ON;
	DECLARE @maxId INT
	UPDATE table_key
	SET @maxId = key_value,key_value = key_value + 1 
	WHERE table_name=@table_name
	SELECT @maxId

end

 结论：适用中型应用，此方案解决了分表，关联表插入记录的问题。但是无法满足高并发性能要求。同时也存在单点问题，如果这个数据库cash掉的话……

我们目前正头痛这个问题，因为我们的高并发常常出现数据库访问超时，瓶颈就在这个MaxId表。我们也有考虑使用分布式缓存（eg：memcached）缓存第一次访问MaxId表数据，以提高再次访问速度，并定时用缓存数据更新一次MaxId表，但我们担心的问题是：

a)         倘若缓存失效或暴掉了，那缓存的MaxId没有更新到数据库导致数据丢失，必须停掉站点来执行Select max(id)各个表来同步MaxId表。

b)         分布式缓存不是一保存下去，其他服务器上就立马可以获取到的，即数据存在不确定性。（其实也是缓存的一个误用，缓存应该用来存的是频繁访问并且很少改动的内容）

         改进方案：

整体思想：建立两台以上的数据库ID生成服务器，每个服务器都有一张记录各表当前ID的MaxId表，但是MaxId表中Id的增长步长是服务器的数量，起始值依次错开，这样相当于把ID的生成散列到每个服务器节点上。例如：如果我们设置两台数据库ID生成服务器，那么就让一台的MaxId表的Id起始值为1（或当前最大Id+1），每次增长步长为2，另一台的MaxId表的ID起始值为2（或当前最大Id+2），每次步长也为2。这样就将产生ID的压力均匀分散到两台服务器上，同时配合应用程序控制，当一个服务器失效后，系统能自动切换到另一个服务器上获取ID，从而解决的单点问题保证了系统的容错。（Flickr思想）

但是要注意：1、多服务器就必须面临负载均衡的问题；2、倘若添加新节点，需要对原有数据重新根据步长计算迁移数据。

结论：适合大型应用，生成Id较短，友好性比较好。（强烈推荐）

2、COMB数据类型的基本设计思路是这样的：既然GUID数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么能不能通过组合的方式，保留GUID的10个字节，用另6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与GUID组合起来，在保留GUID的唯一性的同时增加了有序性，以此来提高索引效率。

在NHibernate中，COMB型主键的生成代码如下所示：

/// <summary> /// Generate a new <see cref="Guid"/> using the comb algorithm. 
        /// </summary> 
        private Guid GenerateComb()
        {
            byte[] guidArray = Guid.NewGuid().ToByteArray();

            DateTime baseDate = new DateTime(1900, 1, 1);
            DateTime now = DateTime.Now;

            // Get the days and milliseconds which will be used to build    
            //the byte string    
            TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks);
            TimeSpan msecs = now.TimeOfDay;

            // Convert to a byte array        
            // Note that SQL Server is accurate to 1/300th of a    
            // millisecond so we divide by 3.333333    
            byte[] daysArray = BitConverter.GetBytes(days.Days);
            byte[] msecsArray = BitConverter.GetBytes((long)
              (msecs.TotalMilliseconds / 3.333333));

            // Reverse the bytes to match SQL Servers ordering    
            Array.Reverse(daysArray);
            Array.Reverse(msecsArray);

            // Copy the bytes into the guid    
            Array.Copy(daysArray, daysArray.Length - 2, guidArray,
              guidArray.Length - 6, 2);
            Array.Copy(msecsArray, msecsArray.Length - 4, guidArray,
              guidArray.Length - 4, 4);

            return new Guid(guidArray);
        }

 结论：适合大型应用。即保留GUID的唯一性的同时增加了GUID有序性，提高了索引效率；解决了关联表业务问题；生成的Id不够友好；占据了32位。（强烈推荐）

3、自己写编码规则

优点：全局唯一Id，符合业务后续长远的发展（可能具体业务需要自己的编码规则等等）。

缺陷：根据具体编码规则实现而不同；还要考虑倘若主键在业务上允许改变的，会带来外键同步的麻烦。

我这边写两个编码规则方案：（可能不唯一，只是个人方案，也请大家提出自己的编码规则）

1)         12位年月日时分秒+5位随机码+3位服务器编码  （这样就完全单机完成生成全局唯一编码）---共20位

缺陷：因为附带随机码，所以编码缺少一定的顺序感。（生成高唯一性随机码的方案稍后给给出程序）

2)         12位年月日时分秒+5位流水码+3位服务器编码 （这样流水码就需要结合数据库和缓存）---共20位   （将影响顺序权重大的“流水码”放前面，影响顺序权重小的服务器编码放后）

缺陷：因为使用到流水码，流水码的生成必然会遇到和MaxId、序列表、Sequence方案中类似的问题

（为什么没有毫秒？毫秒也不具备业务可读性，我改用5位随机码、流水码代替，推测1秒内应该不会下99999[五位]条语法）

 

结论：适合大型应用，从业务上来说，有一个规则的编码能体现产品的专业成度。（强烈推荐）