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。