今天完成的事情：

1:做了个分享会的ppt,讲了下关于深度思考自增ID的看法

2:把昨天的404错误解决了

明天计划的事情：

继续写关联数据库,完善这个文件

遇到的问题:

昨天晚上师兄分享会后才知道我今天要做分享会,然后就很懵,

太突然了,就只能强行怼一波,结果一天就这么过去了...

找这个自增id的分享和拓展搞了一天,翻了不少资料,但是还是有错的地方和理解不够深入的地方...

不过听了老大的讲解,很受启发,打算在收获上整理好贴上去

收获：

1:

什么是分布式数据库:把数据分布在多台机器上,

分布式数据库系统通常使用较小的计算机系统,每台计算机课单独放在一个地方,每台计算机中都有可能有DBMS的一份完整拷贝副本,或者部分拷贝副本,并具有自己局部的数据库,位于不同地点的许多计算机通过网络互相连接,共同组成物理上分布的大型数据库

2:程序和数据库可以是分布式的.数据库从一个实例,分成多个实例,假设有一个分表操作,把1个亿的数据分成十张表,这十张表如果使用自增id的话,就肯定有重复的地方.所以不能这么做,因为主键重复了,不知道去哪里找.

分布式系统是在多台机器上部署同样的服务,相同的服务分布在多台服务器上,即把数据库分成很多个部分,有相同的部分,也有每个数据库各自不同的部分..

3:uuid组成是由当前时间,随机数,和机器识别号组合而成,不会出现重复的情况

UUID的方法:

public static void main(String[] args) {

        String s = UUID.randomUUID().toString();

        System.out.println(s);

    }

4;主键:这个表中通过这个字段,可以唯一确定一条数据,一般来讲,一般用id来表示这做着件事

特殊情况特殊选择(详见10)

5:

ID有几种生成方式:

1:手动插入

2:自动增长

6:

系统如何保证单一数据库ID唯一?

生成的记录里存有id,新增的那个比最大值+1

7:

高并发下自增ID的坏处:

一秒钟要同时处理多条数据,只能加锁一个个按顺序给数据.锁就非常影响性能.如果不加锁,线程不安全,数据就会乱

所以自增ID使用在单库高并发写入时会出现问题

解决方式不只UUID一种.高并发情况下需求是要产生一个不重复的数字.

8:

所有语言都提供生成uuid的方法,调用这个方法就可以在底层生成一个不会重复的字符串出来,把它设置成数据库的id即可

截取当前时间戳+3~5个随机数来确保不会重复

9:

UUID的坏处:

索引非常大,不好标识,太长了

可以使用id center(简单知道)一种策略

用自己的数字,保证它不重复

每次服务,自动拿一批id(请求量变少),每次用只要没用完,就继续拿里面剩余的id来用

10;

设计数据库的时候,推荐用一种没有意义的数字或字符串来做主键

因为如果用id的话,id可能会被引用,和别的数据关联.所以关联一旦变化的话,就会很麻烦.所以选择使用没有意义的数字和编号是想让他保证不变,只用来做唯一标识,不和其他东西关联(最佳实现)

所有的设计方案都和当前业务场景有关系.也就是按需求来选择使用的方法