Snowflake算法 ID生成
http://blog.csdn.net/w200221626/article/details/52064976
使用UUID或者GUID產生的ID沒有規則
Snowflake算法是Twitter的工程師為實現遞增而不重復的ID實現的
從圖上看除了第一位不可用之外其它三組均可浮動站位，據說前41位就可以支撐到2088年，10位的可支持1023台機器，最后12位序列號可以在1毫秒內產生4095個自增的ID。
數據中主鍵有多種方式：數據庫自增、程序生成。程序生成一般采用的是snowflake 算法。這個算法在網上有很多解釋，這里就不做過多的解釋。
生成的id大致有以下組成：
Snowflake算法一般生成的每一個ID都是64位的整型數，它的核心算法也比較簡單高效，結構如下：
41位的時間序列，精確到毫秒級，41位的長度可以使用69年。時間位還有一個很重要的作用是可以根據時間進行排序。
5位的數據中心標識，5位的長度最多支持部署32個節點。
5位的機器標識，8位的長度最多支持部署255個節點。
12位的計數序列號，序列號即一系列的自增id，可以支持同一節點同一毫秒生成多個ID序號，12位的計數序列號支持每個節點每毫秒產生4095個ID序號。
最高位是符號位，始終為0，不可用。
根據生成規則和實際代碼：
（有關算法詳解：https://segmentfault.com/a/1190000011282426#articleHeader2）
在多線程中使用要加鎖。
C# 實現 Snowflake算法
/// <summary>
/// 動態生產有規律的ID Snowflake算法是Twitter的工程師為實現遞增而不重復的ID實現的
/// http://blog.csdn.net/w200221626/article/details/52064976
/// C# 實現 Snowflake算法
/// </summary>
public class Snowflake
{
private static long machineId;//機器ID
private static long datacenterId = 0L;//數據ID
private static long sequence = 0L;//計數從零開始
private static long twepoch = 687888001020L; //唯一時間隨機量
private static long machineIdBits = 5L; //機器碼字節數
private static long datacenterIdBits = 5L;//數據字節數
public static long maxMachineId = -1L ^ -1L << (int)machineIdBits; //最大機器ID
private static long maxDatacenterId = -1L ^ (-1L << (int)datacenterIdBits);//最大數據ID
private static long sequenceBits = 12L; //計數器字節數，12個字節用來保存計數碼
private static long machineIdShift = sequenceBits; //機器碼數據左移位數，就是后面計數器占用的位數
private static long datacenterIdShift = sequenceBits + machineIdBits;
private static long timestampLeftShift = sequenceBits + machineIdBits + datacenterIdBits; //時間戳左移動位數就是機器碼+計數器總字節數+數據字節數
public static long sequenceMask = -1L ^ -1L << (int)sequenceBits; //一微秒內可以產生計數，如果達到該值則等到下一微妙在進行生成
private static long lastTimestamp = -1L;//最后時間戳
private static object syncRoot = new object();//加鎖對象
static Snowflake snowflake;
public static Snowflake Instance()
{
if (snowflake == null)
snowflake = new Snowflake();
return snowflake;
}
public Snowflake()
{
Snowflakes(0L, -1);
}
public Snowflake(long machineId)
{
Snowflakes(machineId, -1);
}
public Snowflake(long machineId, long datacenterId)
{
Snowflakes(machineId, datacenterId);
}
private void Snowflakes(long machineId, long datacenterId)
{
if (machineId >= 0)
{
if (machineId > maxMachineId)
{
throw new Exception("機器碼ID非法");
}
Snowflake.machineId = machineId;
}
if (datacenterId >= 0)
{
if (datacenterId > maxDatacenterId)
{
throw new Exception("數據中心ID非法");
}
Snowflake.datacenterId = datacenterId;
}
}
/// <summary>
/// 生成當前時間戳
/// </summary>
/// <returns>毫秒</returns>
private static long GetTimestamp()
{
//讓他2000年開始
return (long)(DateTime.UtcNow - new DateTime(2000, 1, 1, 0, 0, 0, DateTimeKind.Utc)).TotalMilliseconds;
}
/// <summary>
/// 獲取下一微秒時間戳
/// </summary>
/// <param name="lastTimestamp"></param>
/// <returns></returns>
private static long GetNextTimestamp(long lastTimestamp)
{
long timestamp = GetTimestamp();
int count = 0;
while (timestamp <= lastTimestamp)//這里獲取新的時間,可能會有錯,這算法與comb一樣對機器時間的要求很嚴格
{
count++;
if (count > 10)
throw new Exception("機器的時間可能不對");
Thread.Sleep(1);
timestamp = GetTimestamp();
}
return timestamp;
}
/// <summary>
/// 獲取長整形的ID
/// </summary>
/// <returns></returns>
public long GetId()
{
lock (syncRoot)
{
long timestamp = GetTimestamp();
if (Snowflake.lastTimestamp == timestamp)
{ //同一微妙中生成ID
sequence = (sequence + 1) & sequenceMask; //用&運算計算該微秒內產生的計數是否已經到達上限
if (sequence == 0)
{
//一微妙內產生的ID計數已達上限，等待下一微妙
timestamp = GetNextTimestamp(Snowflake.lastTimestamp);
}
}
else
{
//不同微秒生成ID
sequence = 0L;
}
if (timestamp < lastTimestamp)
{
throw new Exception("時間戳比上一次生成ID時時間戳還小，故異常");
}
Snowflake.lastTimestamp = timestamp; //把當前時間戳保存為最后生成ID的時間戳
long Id = ((timestamp - twepoch) << (int)timestampLeftShift)
| (datacenterId << (int)datacenterIdShift)
| (machineId << (int)machineIdShift)
| sequence;
return Id;
}
}
}
復制代碼
復制代碼
[TestClass]
public class SnowflakeUnitTest1
{
/// <summary>
/// 動態生產有規律的ID Snowflake算法是Twitter的工程師為實現遞增而不重復的ID實現的
/// </summary>
[TestMethod]
public void SnowflakeTestMethod1()
{
var ids = new List<long>();
for (int i = 0; i < 1000000; i++)//測試同時100W有序ID
{
ids.Add(Snowflake.Instance().GetId());
}
for (int i = 0; i < ids.Count - 1; i++)
{
Assert.IsTrue(ids[i] < ids[i+1]);
}
}
}
namespace ConsoleApplicationTester
{
class Program
{
static void Main(string[] args)
{
for (int i = 0; i < 1000; i++)
{
Console.WriteLine("開始執行 " + DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss:ffffff") + " " + Snowflake.Instance().GetId());
Console.WriteLine("Snowflake.maxMachineId:" + Snowflake.maxMachineId);
}
}
}
}
“雪花”項目：Microsoft探索在.NET中實現手工內存管理
http://www.infoq.com/cn/news/2017/09/snowflake
來自Microsoft研究院、劍橋大學和普林斯頓大學的一些研究人員構建了一個.NET的分支，實現了在運行時中添加支持手工內存管理的API。研究方法的細節及所獲得的性能提升發表在名為“Project Snowflake: Non-blocking Safe Manual Memory Management in .NET”（“雪花”項目：非阻塞的、安全的.NET手工內存管理）的論文中。
“雪花“項目意在實現.NET中的手工內存管理，這一改進被認為對一些應用是非常有用。C#、.NET等現代編程語言都采用了垃圾回收機制，使編程人員得以從管理對象的任務中解放出來，這一機制的優點廣為人知，涉及提高生產力、改進程序穩定性、內存安全及防止惡意操作等方面。但是垃圾回收機制需要付出一些性能上的代價，盡管這在很多情況下不易被察覺，但是在一些情況下還是存在問題的。“雪花”項目的研究人員就指出，對於在具有上百GB堆內存的系統上運行數據分析和流處理任務，就可受益於手工內存管理。
“雪花”項目所引入的手工內存管理是與垃圾回收機制並行工作的，開發人員一般情況下使用的是垃圾回收機制，但在環境需要時也可以選擇手工內存管理。該引入到運行時中的改進並不會對已有應用產生影響，並且會改進多線程應用的性能。“雪花”項目實現了“在程序任一位置分配和釋放獨立對象，並確保手工管理對象同樣享有完全的類型安全和時序安全，即使存在並發訪問時。”
“雪花”中提出了兩個新概念，即對象“所有者”（Owner）和“護盾”（Shield），它們實現為CoreCLR和CoreFX層級的API。“所有者”表示了棧或堆中的一個位置，保存了對手工堆中分配對象的唯一引用。“所有者”獲取自“護盾”，而引入“護盾”是為了避免手工對象在被多個線程訪問時重分配（deallocate）。“護盾”確保了當最后使用一個對象的線程重分配該對象后，才從堆中移除該對象。論文中是如下詳細闡述該機制的：
我們的解決方案……受到了無鎖數據結構研究中的“風險指針”（Hazard Pointer）這一概念的啟發。我們引入了一種機制，當線程想要通過其中一個“所有者”位置訪問手工對象時，這一意圖將會發布在線程本地狀態（TLS，Thread-Local State）中。此注冊過程可看成是創建了一個“護盾”，該“護盾”將保護對象不會被重分配，並授權發布注冊的線程可直接訪問對象，例如調用對象的方法，或是轉換（mutate）對象的字段。同時，不允許任何線程（同一線程或另一個線程）重分配對象及回收（reclaim）對象的內存。一旦客戶代碼不再需要訪問該對象，就可以釋放（dispose）“護盾”，即從對象的TLS中移除了指向該對象的引用。直接訪問從“護盾”獲取的對象是不安全的操作，因為在釋放“護盾”后，實際的重分配操作依然允許繼續。
論文中提供了一系列給定場景下的測試結果，表明使用“雪花”項目的性能相比於垃圾回收機制取得了改進。其中，“在峰值工作集上獲得了高達三倍的性能提高，在運行時上取得了兩倍的性能提高”。測試結果給出了很好的性能改進。這是因為當對象池非常大時，垃圾回收為釋放內存需要花費很多時間遍歷對象圖。
Microsoft並未詳述是否有規划在.NET中加入“雪花”項目。但考慮到這是一種非侵入式的和安全的機制，我們希望在.NET的未來版本中能集成類似的功能。
查看英文原文： Microsoft Explores Manual Memory Management in .NET with Snowflake