今天完成的事情
1. Spring Cloud Bus 刷新配置
2. 聚集索引与非聚集索引
3. 了解服务链路追踪
4. Zipkin Server demo

收获

1. 聚集索引与非聚集索引

【聚集索引】：

聚集索引是使用一个唯一且不为空的主键来对所有的数据进行组织。特点是数据在逻辑上一定是连续的，但是在物理地址上不一定是连续的。

我们常用的自增主键就是一种聚集索引，数据存入之后以主键值以节点值把数据存到了一个 b+ 树中（数据位于叶节点，其他节点里面只有主键的信息）。

聚集索引的作用就是把数据以索引的格式存放，把数据【表】以【索引】的数据结构存放，这就是聚集索引。这也是为什么一张表里面聚集索引只能有一个。

聚集索引让数据库的查询速度提升，但是写入速度下降，因为需要维持索引结构的正确。

【非聚集索引】：

非聚集索引与聚集索引一样，以平衡树的结构存放，但是节点存的是被索引的字段，叶节点存的是聚集索引的主键。

非聚集索引是单独存放的，每建立一个非聚集索引，被索引的字段都会被取出来，重新构建一个平衡树。这样就会使用更多的空间去存储。

数据库如何搜索数据？

通过聚集索引的字段可以直接选出需要的数据，但是非聚集索引需要先得到数据的主键，然后去聚集索引里面得到数据。

【索引覆盖】：

前面我们是说非聚集索引可能需要通过聚集索引才能获取到需要的数据。

索引覆盖是一种查询数据的特殊情况，即不需要通过聚集索引就可以获取到所需要的数据。

比如我下面这个图里面就可以看到，红框里面显示 using index 就说明用到了索引覆盖。

这个表中我对 email 这个字段做了唯一索引（非聚集索引），从上面的分析里面可以看到这些非聚集索引里面存的是主键值，这个小例子就可以证明这一点。我确实从非聚集索引里面直接获取到了聚集索引的值。

如果需要的话我们可以做的更加复杂，非聚集索引里面加更多的字段。试试是否我们需要的数据只要和输入的关键词数据在同一个索引里面的话就可以做到索引覆盖。

遇到的问题

1. 昨天未完成的 Spring Cloud Bus 刷新配置问题

原因：

昨天一开始做的时候在测的本地配置文件刷新，我修改的配置是项目里面的，而不是 target 里面的配置文件

解决的办法：

修改编译后的 target 文件夹里面的配置，然后再 post 刷新。

2. 关于 zipkin

在 spring cloud 1.x 的时候是可以做到集成在项目里面的，但是 spring cloud 2.X 的时候 zipkin 官方已经不建议这样做了。所以我们需要单独开启 zipkin 服务，然后在项目里面使用就好。这样的一个不方便的地方就是我们没法在 eureka 里面注册 zipkin 服务了。

这个问题可以解决，但是官方不建议这样做，而且做起来很麻烦。

明天的计划

1. 链路存储自定义数据

2. 微服务监控