架构设计-我的一个支持异步拉取数据和本地缓存client是如何设计的
最近的工作内容是封装一个高性能的sdk，以便和我们的配置中心进行交互，这里整理一下我是如何设计
1. 需求分析
- 我们要支持和配置中心的交互（网络IO）
- 支持客户端缓存功能，并且支持断电重启（内存缓存+文件缓存）
-
配置中心没有推送功能，sdk需要进行轮询（使用NIO网络模型进行轮询）
- 这个点其实设计的并不好，最好是开启一个长链接，由服务端推送请求是最佳实现，但是因为配置中心和客户端之间有一个中间层，无法实现长链接，不过这两个在实现上是类似的
2. 任务分解
- 针对网络IO 提供两套模型
- 当缓存中没有所需要的数据的时候，使用BIO直接读服务端（缓存击穿）
- 当缓存的存在的时候， 将缓存的数据添加到轮询队列中，等待下一次异步同步更新
- 针对缓存设计
- 内存缓存：除了需要提供一个数据缓存，还需要提供一个状态同步集合来标记缓存中数据的状态，比如是否超时，是否有效等
ps : 为什么设计成数据和状态分离 -> 为了更高的可控性和解藕 1.如果需要状态特殊处理的时候只需要拿出状态队列就可以进行处理了不需要动缓存 2. 如果状态需要添加字段或者逻辑，只需要修改对应的状态队列即可，不需要修改数据缓存
- 文件缓存： 这个本质上很内存缓存相似，只有一个点就是当使用nio进行数据同步的时候，nio从网络中拉取的新数据需要同步更新缓存和文件，此时的文件操作应该使用nio保证不堵塞。
- 轮询方法
我在框架中使用的NIO网络框架是vert.x 其实可以理解成java中的promise方法
这里我做的轮询逻辑其实非常简单过程如下
- 拿到需要进行轮询队列
- for循环发起NIO网络请求，并且处理结果
- 更新缓存状态（更新缓存，处理超时等问题）
还需要那些改进？
- 需要添加一个速率控制器，考虑这样一个场景如果轮询发起的请求过大，将可能会把配置中心打垮，所以sdk需要控制请求的速率动态的调整qps来保证服务的稳定。
3. sdk整体的架构图如下
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
