当时订单项目要生成一个全局的唯一ID。

我的理解：

全局唯一： 不能出现重复的ID号，既然是唯一标识，这是最基本的要求
趋势递增： 在Mysql的innoDB引擎使用的是聚集索引，由于多数RDBMS使用B+树的数据结构来存储索引数据，在主键的选择上面，我们应该尽量使用有序的主键保证写入性能。
单调递增： 保证下一个ID一定大于上一个ID,例如事务版本号，IM增量消息，排序等特殊需求。
信息安全 ：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定url即可；如果是订单号就更危险了，竞争对手可以直接知道我们一天的单量。所以在一些应用场景下，需要ID无规则不规则，让竞争对手不好猜。
含时间戳： 这样就能够在开发中快速了解这个分布式id的生成时间

当时选择使用的UUID

如果只考虑唯一性，uuid是ok的，但是它是无序的，入数据库性能差
那数据库自增ID机制适合做分布式ID吗？
不合适。
系统水平扩展比较困难：
所以系统水平扩展方案复杂难以实现。
数据库压力很大,每次获取ID都要读一次数据库,非常影响性能,不符合分布式ID里面的延迟低和要高QPS的规则(在高并发下,如果都去数据库里面获取id,那是非常影响性能的)。

UUID优缺点：

优点：
能够保证独立性，程序可以在不同的数据库间迁移，效果不受影响。
保证生成的ID不仅是表独立的，而且是库独立的，这点在你想切分数据库的时候尤为重要。
。
缺点：
比较占地方，和INT类型相比，存储一个UUID要花费更多的空间。
使用UUID后，URL显得冗长，不够友好。

而且UUID索引很慢

解决问题：

去扒拉一下资料，然后又去网上查了一下这方面的问题，找到了解决类似问题的方法：

最后解决方案使用雪花算法：

为什么使用雪花算法？
在复杂的分布式系统中，往往需要对大量的数据和消息进行唯一标识。
Twitter《吹特》的分布式自增ID算法，snowflake《思no飞科》每秒能够产生26万个自增可排序的ID。

  1. Twitter的雪花算法生成ID能够按照时间有序生成
  2. 雪花算法生成id的结果是一个64bit大小的整数，为一个long型
  3. 分布式系统内不会产生ID碰撞并且效率较高

雪花算法可以保证：


所有生成的id按时间趋势递增；
整个分布式系统内不会产生重复id(因为有datacenterId（center森特）和workerId（沃克 ）来做区分)
邢朋辉 ：
雪花算法不会重复
因为有机器码
每个应用启动的时候注册到redis, 由redis来分配机器id
简单原理：
雪花算法会生成一个64位的二进制数据，为一个Long型
配置**：**
为了保证不重复，我们给每个部署的节点都配置机器id：
20200720183316261.png

项目中高并发问题的解决方案

1、尽量使用缓存技术来做：

用户缓存，页面缓存等一切缓存，使用特定的机制进行刷新。利用消耗内存空间来换取用户的效率，同时减少数据库的访问次数。
2、把数据库的查询语句进行优化，一般复杂的SQL语句就不要使用ORM框架自带的做法来写，采用自己来写SQL，例如hibernate的hql中的复杂语句就会很耗时。

3、优化数据库的表结构，在关键字、主键、访问率极高的字段中加入索引。但尽量只是在数字类型上面加，因为使用字段is null 的时候，索引的效果就会失效。

4、报表统计的模块，尽量使用定时任务执行，如果非要实时进行刷新，那么就可以采用缓存来做数据。

5、可以使用静态页面的地方，尽量使用静态页面，减少页面的解析时间。同时页面中的图片过多时，可以考虑把图片单独做成一个服务器，这样可以减少业务服务器的压力。

6、使用集群的方式来解决单台服务器的性能问题。

7、把项目拆分成多个应用小型服务器的形式来进行部署。采用数据同步机制（可以使用数据库同步形式来做）达到数据一致性。

8、使用负载均衡模式来让每一个服务器资源进行合理的利用。

9、缓存机制中，可以使用redis来做内存数据库缓存起来。也可以使用镜像分担，这样可以让两台服务器进行访问，提高服务器的访问量。
[

](https://blog.csdn.net/weixin_45151795/article/details/105615927)

《关于项目上线》

我们测试的，单机可以支持300多订单。
甲方项目具体流量不清楚。