id生成演算法

1. 請教一個生成唯一id的演算法是否存在重復

只有 com_create_guid 生成全局唯一標識符（GUID）
可確切的保證在同一伺服器中不會重復
多台伺服器間是否會重復，沒有測試不能確認
而 GUID 是號稱全球唯一的

2. hibernate mapping ID生成方式

1) assigned
主鍵由外部程序負責生成，無需Hibernate參與。

2) hilo
通過hi/lo 演算法實現的主鍵生成機制，需要額外的資料庫表保存主
鍵生成歷史狀態。

3) seqhilo
與hilo 類似，通過hi/lo 演算法實現的主鍵生成機制，只是主鍵歷史
狀態保存在Sequence中，適用於支持Sequence的資料庫，如Oracle。

4) increment
主鍵按數值順序遞增。此方式的實現機制為在當前應用實例中維持
一個變數，以保存著當前的最大值，之後每次需要生成主鍵的時候
將此值加1作為主鍵。
這種方式可能產生的問題是：如果當前有多個實例訪問同一個數據
庫，那麼由於各個實例各自維護主鍵狀態，不同實例可能生成同樣
的主鍵，從而造成主鍵重復異常。因此，如果同一資料庫有多個實
例訪問，此方式必須避免使用。

5) identity
採用資料庫提供的主鍵生成機制。如DB2、SQL Server、MySQL
中的主鍵生成機制。

6) sequence
採用資料庫提供的sequence 機制生成主鍵。如Oralce 中的
Sequence。

7) native
由Hibernate根據底層資料庫自行判斷採用identity、hilo、sequence
其中一種作為主鍵生成方式。

8) uuid.hex
由Hibernate基於128 位唯一值產生演算法生成16 進制數值（編碼後
以長度32 的字元串表示）作為主鍵。

9) uuid.string
與uuid.hex 類似，只是生成的主鍵未進行編碼（長度16）。在某些
資料庫中可能出現問題（如PostgreSQL）。

10) foreign
使用外部表的欄位作為主鍵。
一般而言，利用uuid.hex方式生成主鍵將提供最好的性能和資料庫平台適
應性。

另外由於常用的資料庫，如Oracle、DB2、SQLServer、MySql 等，都提
供了易用的主鍵生成機制（Auto-Increase 欄位或者Sequence）。我們可以在數
據庫提供的主鍵生成機制上，採用generator-class=native的主鍵生成方式。
不過值得注意的是，一些資料庫提供的主鍵生成機制在效率上未必最佳，
大量並發insert數據時可能會引起表之間的互鎖。
資料庫提供的主鍵生成機制，往往是通過在一個內部表中保存當前主鍵狀
態（如對於自增型主鍵而言，此內部表中就維護著當前的最大值和遞增量），
之後每次插入數據會讀取這個最大值，然後加上遞增量作為新記錄的主鍵，之
後再把這個新的最大值更新回內部表中，這樣，一次Insert操作可能導致數據
庫內部多次表讀寫操作，同時伴隨的還有數據的加鎖解鎖操作，這對性能產生
了較大影響。
因此，對於並發Insert要求較高的系統，推薦採用uuid.hex 作為主鍵生成
機制。

3. 如何為一個實例生成一個唯一的ID

，以一些特定的信息為基礎，生成設備的唯一標識。 首先，演算法角度，常用的有UUID、摘要兩種。這兩種演算法都是以特定的數據為基礎，生成一個唯一的、固定長度的字元串。

4. sessionId的生成機制是什麼

跟IP和埠這些無關吧，應該跟客戶端，瀏覽器這些有關。當瀏覽器第一次請求時，伺服器創建一個session對象，同時生成一個sessionId，並在此次響應中將sessionId 以響應報文的方式些回客戶端瀏覽器內存或以重寫url方式送回客戶端，來保持整個會話。關閉此瀏覽器窗口，其內存中的sessionId也就隨之銷毀。重新請求時，會重新生成一個sessionId給客戶端瀏覽器，並存在瀏覽內存中。

SessionID 值是使用保證唯一性和隨機性的演算法生成的，其中保證唯一性的目的是確保會話不沖突，保證隨機性的目的是確保懷有惡意的用戶不能使用新的 SessionID 來計算現有會話的 SessionID。

5. 描述Hibernate中的ID生成器

1) assigned
主鍵由外部程序負責生成，無需Hibernate參與。
2) hilo
通過hi/lo 演算法實現的主鍵生成機制，需要額外的資料庫表保存主鍵生成歷史狀態。
3) seqhilo
與hilo 類似，通過hi/lo 演算法實現的主鍵生成機制，只是主鍵歷史狀態保存在Sequence中，適用於支持Sequence的資料庫，如Oracle。
4) increment
主鍵按數值順序遞增。此方式的實現機制為在當前應用實例中維持一個變數，以保存著當前的最大值，之後每次需要生成主鍵的時候將此值加1作為主鍵。
這種方式可能產生的問題是：如果當前有多個實例訪問同一個資料庫，那麼由於各個實例各自維護主鍵狀態，不同實例可能生成同樣的主鍵，從而造成主鍵重復異常。因此，如果同一資料庫有多個實例訪問，此方式必須避免使用。
5) identity
採用資料庫提供的主鍵生成機制。如DB2、SQL Server、MySQL中的主鍵生成機制。
6) sequence
採用資料庫提供的sequence 機制生成主鍵。如Oralce 中的Sequence。
7) native
由Hibernate根據底層資料庫自行判斷採用identity、hilo、sequence其中一種作為主鍵生成方式。
8) uuid.hex
由Hibernate基於128 位唯一值產生演算法生成16 進制數值（編碼後以長度32 的字元串表示）作為主鍵。
9) uuid.string
與uuid.hex 類似，只是生成的主鍵未進行編碼（長度16）。在某些資料庫中可能出現問題（如PostgreSQL）。
10) foreign
使用外部表的欄位作為主鍵。

6. 如何為每部Android手機生成一個唯一的ID

這種方法是，以一些特定的信息為基礎，生成設備的唯一標識。
首先，演算法角度，常用的有UUID、摘要兩種。這兩種演算法都是以特定的數據為基礎，生成一個唯一的、固定長度的字元串。這里選擇UUID。

其次，計算的基礎數據，建議選擇divice_id和android_id。原因是，1）這兩個標識雖然不能抵抗wipe操作，但受用戶的行為影響比較小；2）如果正常獲取，都是唯一的；③如果不能正常獲取，結果也是固定的，不會頻繁變化。

再次，優先順序的考慮。從這兩個標識的缺點考慮。
1）device_id。
①不能標識非手機設備，例如Pad。
②許可權問題，因為用戶的反感。
③獲取異常，廠商定製系統中存在的bug，致使返回結果為空，或者為一串「0」或「*」。
④對於雙卡雙待手機，會返回兩個device_id。
2）android_id。
①Android2.3以前，系統Bug，導致不同的設備產生相同的結果：9774d56d682e549c。
②有些可能返回null。
③設備差異：對於CDMA設備，與device_id返回相同的值。
綜合考慮，device_id不能標識某些pad，以及用戶的許可權問題，是我們不能接受的，所以優先使用android_id。對於android_id返回為null的情況，再考慮使用device_id。

最後，當android_id和device_id都返回異常的情況，我們可以隨機生成一個UUID。