淘宝Diamond架构分析 cache编程zkJNIBorland
程序员文章站
2022-07-13 22:54:54
...
阅读原文请点击：http://click.aliyun.com/m/23323/
摘要： 花了两天的时间研究了下Diamond，因为写得比较急，而且并没有使用过，只是单纯的做逆向建模，所以难免会有细节缺失，后面会时不时过来看看，然后做些补充。 背景知识 早期的应用都是单体的，配置修改后，只要通过预留的管理界面刷新reload即可。后来，应用开始拆分，从单一系统拆分成多个子系统，每个子系统还会对应多个运行实例，就开始面临一些问题： 1. 配置分散在多个业务
花了两天的时间研究了下Diamond，因为写得比较急，而且并没有使用过，只是单纯的做逆向建模，所以难免会有细节缺失，后面会时不时过来看看，然后做些补充。
背景知识
早期的应用都是单体的，配置修改后，只要通过预留的管理界面刷新reload即可。后来，应用开始拆分，从单一系统拆分成多个子系统，每个子系统还会对应多个运行实例，就开始面临一些问题：
1. 配置分散在多个业务子系统里，对同一配置的翻译在多个子系统里经常不一致。比如订单和购物车都有货币类型的配置，如果购物车上了一种新的货币类型而订单却没有相应同步增加配置项就会造成程序错误。
2. 将配置收敛成一个公有服务，可以有效改善，但是又会带来其他问题。在复杂应用里，修改一个配置项，无法确切的知道需要刷新哪些相关子系统。最终只能做全量刷新，甚至是停机发布。这对于一些停机敏感的应用例如电商几乎是无法接受的。
3. 配置收敛后，配置中心成了应用中的单点，配置如果挂了，应用也会跟着产生异常甚至挂掉。
Diamond就是为了解决这些问题，它是个高可用的配置中心。
Diamond的配置类型
配置是Diamond的核心域，也是Diamond致力于去解决的问题。Diamond有两个主要配置类型– single和aggr。二者结构如下：
配置结构
Aggr和single相比，少md5多datumId。DatumId是aggr的逻辑主键，aggr下dataId和datumId是1对多的关系，也就是说多条aggr会聚合成一条single，diamond通过merge任务对aggr合并最终生成一条single。
Md5是对content md5编码生成的字符串，用于判断缓存数据相比数据库数据是否不同，缓存数据必须严格与数据库数据一致，diamond并没有数据版本，默认数据库数据是最新的，也就是说如果数据库数据发生回退，即使缓存数据更新也会跟着回退。
Single才有md5，aggr其实并不算是完整的配置（多条aggr一起才是一个完整的配置），所以不需要校验数据是否改变。
整体架构设计
下图是Diamond的组件视图。Diamond主要有ops, sdk, client和server 4个组件。Ops是运维用的配置工具，主要用于下发以及查询配置等；server则是Diamond的后台，处理配置的一些逻辑；sdk则是提供给ops或者其他第三方应用的开发工具包；client则是编程api，它和sdk乍看有点像，其实差别很大，sdk是用于构建前台运维配置程序的，本质是对数据的维护，所有的访问和操作都是直接面向数据库的；而client则是这些数据的消费者，事实上准确的说是diamond的消费者们（各子系统）都是通过client组件对server访问。
进程视图
Diamond server是无中心节点的逻辑集群，读请求都是访问local file，而写请求则会先进入数据库，接着再更新各节点缓存。注意：ops或者其他第三方运维系统（其实就是sdk模块）读取和写入的都是数据库，这很容易理解，缓存会有lag，配置系统必须面向的是实时数据。
Diamond的数据库是单点的，这就可以利用数据库特性保证数据的原子性，一致性和持久性，也就不需要实现类似zk的集群协议，也就不存在leader/follower以及observer等节点角色，它是去中心化的，所有节点都可以接受任意请求。Diamond是典型的读多写少，写一般都来自运维系统例如ops，这种请求量会很小，即使峰值期对数据库的冲击也不会太大。实际上它就是数据库之上的一个保护壳，数据库的数据通过它透出来，也通过它渗进去。
Diamond的同质节点之间会相互通信以保证数据的一致性，每个节点都有其它节点的地址信息，其中一个节点收到变更请求后，首先写入数据库，再通知所有同质节点更新缓存，保证数据的一致性。
为了保证高可用，client会在app端以本地文件形式缓存数据的snapshot，保证即使server不可用时app也可用，这一点和dubbo很相似，所以也完全可以使用diamond搭建dubbo注册中心。
内存缓存
Client端使用的内存cache是一个AtomicReference
它并不是通常理解的内存缓存，而只是一个事件源，只有被监听的配置才会有cache。Cache内聚了group，dataId，md5，content和listener等。
客户端的长轮询任务（下一节将会重点介绍）只轮询被监听的配置，也就是cache的数据。客户端在pull到新数据后首先会更新snapshot，再更新cache，接着全量对比所有cache和它关联的listener的md5信息从而知道配置更新有没有被通知，没有则以cache中的内容作为消息载体通知，通知完成后更新listener的md5。
没被监听的数据不需要轮询，因为diamond提供的读数据api默认会先从服务节点获取实时数据。
在客户端发起长轮询或者服务节点做dump时，都需要对比md5信息以确定是否要推送或者dump。Server端缓存全量缓存了所有配置的md5信息，并会第一时间得到更新，得到更新同时还会推送LocalDataChangeEvent。
无论客户端还是服务端，内存缓存仅仅是为了满足某种功能需求，并不作为读的数据源（客户端只缓存部分数据，服务端不缓存配置内容）。这是基于产品本身定位而来的，产品定位本身就是牺牲一部分速度以降低成本，并且同时提供长轮询机制为时效性要求高的配置做到准实时的变更推送。但在客户端，每个应用的兴趣点都是分散的，平均下来每个应用感兴趣的配置数据并不大。
阅读原文请点击：http://click.aliyun.com/m/23323/
摘要： 花了两天的时间研究了下Diamond，因为写得比较急，而且并没有使用过，只是单纯的做逆向建模，所以难免会有细节缺失，后面会时不时过来看看，然后做些补充。 背景知识 早期的应用都是单体的，配置修改后，只要通过预留的管理界面刷新reload即可。后来，应用开始拆分，从单一系统拆分成多个子系统，每个子系统还会对应多个运行实例，就开始面临一些问题： 1. 配置分散在多个业务
花了两天的时间研究了下Diamond，因为写得比较急，而且并没有使用过，只是单纯的做逆向建模，所以难免会有细节缺失，后面会时不时过来看看，然后做些补充。
背景知识
早期的应用都是单体的，配置修改后，只要通过预留的管理界面刷新reload即可。后来，应用开始拆分，从单一系统拆分成多个子系统，每个子系统还会对应多个运行实例，就开始面临一些问题：
1. 配置分散在多个业务子系统里，对同一配置的翻译在多个子系统里经常不一致。比如订单和购物车都有货币类型的配置，如果购物车上了一种新的货币类型而订单却没有相应同步增加配置项就会造成程序错误。
2. 将配置收敛成一个公有服务，可以有效改善，但是又会带来其他问题。在复杂应用里，修改一个配置项，无法确切的知道需要刷新哪些相关子系统。最终只能做全量刷新，甚至是停机发布。这对于一些停机敏感的应用例如电商几乎是无法接受的。
3. 配置收敛后，配置中心成了应用中的单点，配置如果挂了，应用也会跟着产生异常甚至挂掉。
Diamond就是为了解决这些问题，它是个高可用的配置中心。
Diamond的配置类型
配置是Diamond的核心域，也是Diamond致力于去解决的问题。Diamond有两个主要配置类型– single和aggr。二者结构如下：
配置结构
Aggr和single相比，少md5多datumId。DatumId是aggr的逻辑主键，aggr下dataId和datumId是1对多的关系，也就是说多条aggr会聚合成一条single，diamond通过merge任务对aggr合并最终生成一条single。
Md5是对content md5编码生成的字符串，用于判断缓存数据相比数据库数据是否不同，缓存数据必须严格与数据库数据一致，diamond并没有数据版本，默认数据库数据是最新的，也就是说如果数据库数据发生回退，即使缓存数据更新也会跟着回退。
Single才有md5，aggr其实并不算是完整的配置（多条aggr一起才是一个完整的配置），所以不需要校验数据是否改变。
整体架构设计
下图是Diamond的组件视图。Diamond主要有ops, sdk, client和server 4个组件。Ops是运维用的配置工具，主要用于下发以及查询配置等；server则是Diamond的后台，处理配置的一些逻辑；sdk则是提供给ops或者其他第三方应用的开发工具包；client则是编程api，它和sdk乍看有点像，其实差别很大，sdk是用于构建前台运维配置程序的，本质是对数据的维护，所有的访问和操作都是直接面向数据库的；而client则是这些数据的消费者，事实上准确的说是diamond的消费者们（各子系统）都是通过client组件对server访问。
进程视图
Diamond server是无中心节点的逻辑集群，读请求都是访问local file，而写请求则会先进入数据库，接着再更新各节点缓存。注意：ops或者其他第三方运维系统（其实就是sdk模块）读取和写入的都是数据库，这很容易理解，缓存会有lag，配置系统必须面向的是实时数据。
Diamond的数据库是单点的，这就可以利用数据库特性保证数据的原子性，一致性和持久性，也就不需要实现类似zk的集群协议，也就不存在leader/follower以及observer等节点角色，它是去中心化的，所有节点都可以接受任意请求。Diamond是典型的读多写少，写一般都来自运维系统例如ops，这种请求量会很小，即使峰值期对数据库的冲击也不会太大。实际上它就是数据库之上的一个保护壳，数据库的数据通过它透出来，也通过它渗进去。
Diamond的同质节点之间会相互通信以保证数据的一致性，每个节点都有其它节点的地址信息，其中一个节点收到变更请求后，首先写入数据库，再通知所有同质节点更新缓存，保证数据的一致性。
为了保证高可用，client会在app端以本地文件形式缓存数据的snapshot，保证即使server不可用时app也可用，这一点和dubbo很相似，所以也完全可以使用diamond搭建dubbo注册中心。
内存缓存
Client端使用的内存cache是一个AtomicReference
它并不是通常理解的内存缓存，而只是一个事件源，只有被监听的配置才会有cache。Cache内聚了group，dataId，md5，content和listener等。
客户端的长轮询任务（下一节将会重点介绍）只轮询被监听的配置，也就是cache的数据。客户端在pull到新数据后首先会更新snapshot，再更新cache，接着全量对比所有cache和它关联的listener的md5信息从而知道配置更新有没有被通知，没有则以cache中的内容作为消息载体通知，通知完成后更新listener的md5。
没被监听的数据不需要轮询，因为diamond提供的读数据api默认会先从服务节点获取实时数据。
在客户端发起长轮询或者服务节点做dump时，都需要对比md5信息以确定是否要推送或者dump。Server端缓存全量缓存了所有配置的md5信息，并会第一时间得到更新，得到更新同时还会推送LocalDataChangeEvent。
无论客户端还是服务端，内存缓存仅仅是为了满足某种功能需求，并不作为读的数据源（客户端只缓存部分数据，服务端不缓存配置内容）。这是基于产品本身定位而来的，产品定位本身就是牺牲一部分速度以降低成本，并且同时提供长轮询机制为时效性要求高的配置做到准实时的变更推送。但在客户端，每个应用的兴趣点都是分散的，平均下来每个应用感兴趣的配置数据并不大。
阅读原文请点击：http://click.aliyun.com/m/23323/