BBSSDK数据同步存储原理

简介:

BBSSDK是一套能快速实现discuz论坛移动化的一套解决方案。今天主要讲讲这个产品的数据同步存储原理。

主要从这三个方面:一.存储机制;二.版本控制;三.同步原理。

一.存储机制
首先要理清我们有哪些内容,在对内容进行各种不同程度的存储和持久化。
根据内容类型我们分为:文本和多媒体。主要同步的内容就是文本内容,多媒体内容基本通过URL的形式进行访问,存储方式可以在用户的服务器端和我们提供的(或第三方提供的)对象存储系统。
文本内容又拆分为不同的等级:高频内容,低频内容,冷内容。
高频内容我们根据业务也进行进一步的拆分,核心的业务比如论坛版块、用户组、最新热帖等。进行主要的内容同步。而一些不是核心业务的内容比如家园、博客就没有在我们项目的同步规划内。

低频内容包括有用户,陈贴等,通过异步激活的方式进行数据的同步。

冷内容比如僵尸用户,历史广告数据等,这部分内容就在用户的论坛上而不参与BBSSDK线上逻辑。

理清了需要存储的数据,就需要对各种等级数据进行存储。在存储方案中有两种选择nosql和RDBS,考虑到没有复杂的事务性操作和读写效率,最终选择了mongodb作为线上数据存储服务。mongodb在热数据的查询和raw的快速写入,由于其在数据读写方面由于充分使用速度快的内存而占据优势。一些更高频内容(比如板块列表等)又在redis里面进行持久化,方便高并发的同时减少磁盘的IO。
_1

二.版本控制
怎么去处理内容?当前内容是否最新?需要我们去维护一套内容的版本信息。在用户服务器需要一套,这样可以通知或提交最新的内容;平台也需要一套,知道这些通知或内容是否值得去获取和存储。

由于版本控制要保持内容的最终一致性,这就必须要有一个原子时钟。这个时钟就以用户服务器里的DB时间为标准。

用户服务器根据DB的触发器记录状态缓存在版本信息表里,后提交(或平台发送心跳获取)版本信息通知平台来获取数据。平台根据请求体或返回体里面的时间,或每次成功返回的头信息去维护平台自己的版本信息库。

三.同步原理
同步原理分三个部分:1.传输方式,2.时效性,3.安全性

1.传输方式,选择了http(s)的方式进行数据的推拉同步,首先http的兼容性高,只要是discuz的论坛搭建在虚拟空间也支持,不需要额外的环境配置;二是由于http是TCP协议稳定性好,缺点也就是耗费网络IO增加用时。

2.时效性,涉及到网络同步总会有延迟,怎么做到用户无感知延迟的内容同步?用户的网站千差万别,有些时候总会遇到不可避免的因素,导致获取消息的不及时,怎么解决最终内容的一致性?主要从三个方面进行:a.初始化方式;b.通知队列的消耗方式;c.心跳轮询机制。

a.初始化方式
在论坛插件安装成功后,会发送一个通知给平台。平台根据队列开启线程发起初始化。

初始化由于内容上我们进行了各种颗粒的切割,所以这个初始化不是整个论坛的全量数据同步。而是获取必要的配置信息,再加上高频的热内容同步在平台上。类似CDN的初始化流程。

b.通知队列的消耗方式
在通知队列中的每条通知需要描述当前任务的属性:包含权重,任务细节等。当消费者消耗通知队列的时候,去判断当前任务在版本描述中是否值得去获取,再通过http请求去获取内容,如果遇到不可避免因素导致内容获取失败,就需要对当前任务进行指数型递增下一次的执行时间。这样在不影响健康论坛运行的同时保持问题论坛内容的一致性。

如果一个论坛一直在发送通知而获取不到内容。在一个时间段达到一定数量级,我们可以判断当前论坛已经假死。为保证平台资源的合理利用,对问题论坛进行临时关闭,拉高指数重试,这样如果问题论坛还需要平台提供服务就需要再次提交初始化请求。

c.心跳轮询机制
在定长的时间内,平台会发送请求去目标论坛进行最新版本信息的获取。如果目标论坛没有返回。在多次无效的情况下,平台会判定目标网站已经关闭服务不再发起心跳轮询。

如果论坛用户是卸载了插件应用,就需要重新安装论坛插件,再次初始化服务。

如果论坛用户只是临时关闭服务或论坛出现短暂问题,插件在前端埋下的钩子会在定时内会通过前端用户触发发送平台服务器请求,去唤醒论坛服务,后激活心跳轮询保持服务的正常运行。

3.安全性,a.通信的安全:考虑到信息资产的安全所有的交互都是带签名验证的。这种验证方式使用的是请求体加秘钥的hash算法。秘钥通过mob管理后台进行获取,配置在插件端;b.内容存储安全:平台使用mongdb副本集的方式进行内容的存储。

目录
相关文章
|
存储 文件存储 对象存储
S3存储服务间数据同步工具Rclone迁移教程
目前大多项目我们都会使用各种存储服务,例如oss、cos、minio等。当然,因各种原因,可能需要在不同存储服务间进行数据迁移工作,所以今天就给大家介绍一个比较通用的数据迁移工具Rclone。
S3存储服务间数据同步工具Rclone迁移教程
|
3月前
|
存储 负载均衡 NoSQL
Redis 高可用篇:你管这叫主从架构数据同步原理?
Redis 高可用篇:你管这叫主从架构数据同步原理?
241 5
|
3月前
|
存储 NoSQL 数据库连接
Redis主从模式以及数据同步原理:全量数据同步、增量数据同步
Redis主从模式以及数据同步原理:全量数据同步、增量数据同步
179 0
|
11月前
|
存储 负载均衡 数据中心
带你读《存储漫谈:Ceph原理与实践》——3.2.5 元数据 / 数据同步
带你读《存储漫谈:Ceph原理与实践》——3.2.5 元数据 / 数据同步
|
11月前
|
DataWorks 数据库
带你读《全链路数据治理-全域数据集成》之16:2. 网络连通原理介绍
带你读《全链路数据治理-全域数据集成》之16:2. 网络连通原理介绍
121 0
|
缓存 前端开发 安全
55-微服务技术栈(高级):微服务网关Soul(数据同步原理)
Soul 网关在启动时,会从从配置服务同步配置数据,并且支持推拉模式获取配置变更信息,并且更新本地缓存。而管理员在管理后台,变更用户、规则、插件、流量配置,通过推拉模式将变更信息同步给 Soul 网关,具体是 push 模式,还是 pull 模式取决于配置。关于配置同步模块,其实是一个简版的配置中心。
382 0
深入浅出阿里数据同步神器:Canal原理+配置+实战全网最全解析!
canal 翻译为管道,主要用途是基于 MySQL 数据库的增量日志 Binlog 解析,提供增量数据订阅和消费。 早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。
|
存储 负载均衡 NoSQL
Redis 高可用篇:你管这叫主从架构数据同步原理? (上)
本篇主要带大家全方位吃透 Redis 高可用技术解决方案之一主从复制架构。 本篇硬核,建议收藏慢慢品味,我相信读者朋友会有一个质的提升。如有错误还望纠正,谢谢。关注「码哥字节」设置「星标」第一时间接收优质文章,谢谢读者的支持。
227 0
Redis 高可用篇:你管这叫主从架构数据同步原理? (上)
|
canal 存储 SQL
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
前言 前文架构篇,可以看到 MySQL + Tablestore 非常适合大规模订单系统这一类需求场景。那么,我们首先要做的是,利用 CDC(Change Data Capture) 技术将订单数据实时从 MySQL 同步到 Tablestore 中。对于订单系统的数据同步,我们需要关注同步的稳定性、实时性。目前,存在多款工具可以实现这一功能,他们有的是开源工具如 Canal,有的是阿里云端服务如
978 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇

热门文章

最新文章