有关类朋友圈设计(3) -- 数据库设计&现有技术&流程设计

在写之前,先说说当前的系统架构吧

spring cloud + zuul + eureka + oauth2 + redis + rabbitMq

这个系统是由我搭建的,当时采用的springCloud 版本 Finchley,这点是因为它支持springBoot2.0

注*

网关选zuul是因为当时对zuul比gateway更了解,而且用户量不是很大,现在zuul也遇到了问题,在考虑转gateway

RPC框架选eureka也是基于了解的情况选的,现在不更新了,以后会转Nacos

现有设计到的技术就上面那些了,很简陋.因为服务器采用的阿里云服务器,所以尽量在不扩展技术的情况下去做.

技术就说到这,接下来就是设计数据库表了 (最初版本:可能不是完整的字段)

首先是数据存储表:

CREATE TABLE `activity_record` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '动态id',
  `user_id` varchar(32) NOT NULL DEFAULT '' COMMENT '人员主键',
  `content` longtext NOT NULL COMMENT '内容',
  `time` datetime NOT NULL COMMENT '时间',
  `hot_spot_f` varchar(20) NOT NULL DEFAULT '' COMMENT '热点1',
  `hot_spot_s` varchar(20) NOT NULL DEFAULT '' COMMENT '热点2',
  `hot_spot_t` varchar(20) NOT NULL DEFAULT '' COMMENT '热点3',
  `dept_id` varchar(32) NOT NULL DEFAULT '' COMMENT '部门id',
  `is_delete` tinyint(1) NOT NULL DEFAULT 0 COMMENT '删除标志',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=21 DEFAULT CHARSET=utf8mb4 COMMENT='个人动态表';

CREATE TABLE `activity_like_record` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `user_id` varchar(32) NOT NULL COMMENT '用户id',
  `activity_id` int(11) NOT NULL COMMENT '动态id',
  `create_time` datetime DEFAULT NULL COMMENT '点赞时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COMMENT='点赞记录表';

CREATE TABLE `activity_comment` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `comment_info` varchar(400) DEFAULT NULL COMMENT '评论内容',
  `comment_time` datetime DEFAULT NULL COMMENT '评论时间',
  `parent_id` int(11) DEFAULT NULL COMMENT '父级评论id',
  `lev` tinyint(3) DEFAULT NULL COMMENT '评论等级',
  `user_id` varchar(32) DEFAULT NULL COMMENT '评论人',
  `activity_id` int(11) DEFAULT NULL COMMENT '动态id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COMMENT='评论表';

CREATE TABLE `activity_annex` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `annex_info` varchar(300) DEFAULT NULL COMMENT '附件信息',
  `annex_url` varchar(300) DEFAULT NULL COMMENT '附件路径',
  `annex_type` varchar(50) DEFAULT NULL COMMENT '附件类型',
  `activity_id` int(11) NOT NULL COMMENT '动态id',
  `sort` int(4) DEFAULT NULL COMMENT '排序',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8mb4 COMMENT='动态附件表';

CREATE TABLE `activity_record_draft` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '动态id',
  `user_id` varchar(32) NOT NULL DEFAULT '' COMMENT '人员主键',
  `content` longtext NOT NULL COMMENT '内容',
  `time` datetime NOT NULL COMMENT '时间',
  `hot_spot_f` varchar(20) NOT NULL DEFAULT '' COMMENT '热点1',
  `hot_spot_s` varchar(20) NOT NULL DEFAULT '' COMMENT '热点2',
  `hot_spot_t` varchar(20) NOT NULL DEFAULT '' COMMENT '热点3',
  `dept_id` varchar(32) NOT NULL DEFAULT '' COMMENT '部门id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8 COMMENT='个人动态草稿表';

CREATE TABLE `activity_annex_draft` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `annex_info` varchar(300) DEFAULT NULL COMMENT '附件信息',
  `annex_url` varchar(300) DEFAULT NULL COMMENT '附件路径',
  `annex_type` varchar(50) DEFAULT NULL COMMENT '附件类型',
  `draft_id` int(11) NOT NULL COMMENT '动态id',
  `sort` int(4) DEFAULT NULL COMMENT '排序',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8mb4 COMMENT='草稿动态附件表';

然后到了业务辅助表了,首先聊聊朋友圈架构设计(参考微信架构师许家滔在QCon北京2014上的演讲“微信后台存储架构”)

这里面有一个重要的思想: 时间轴-- 记录本人能看到的所有动态的时间线.

举个例子: 在做的时候原本思维是这样子的

在获取本人能看到的动态,需要查本人所有好友的动态后进行时间排序. 这个对时间复杂性了解的人应该知道在不考虑排序下时间复杂度是O(n)*O(m)

如果添加时间线的概念

针对于每个人都维护了一个时间线那么在任何情况下的时间复杂度都是 O(n) 但 空间上也多了O(n). 但多了个存储.

这是典型的空间换时间的思想

但在针对于公司内部动态中,动态都是可见的,所以在空间上还需要针对其它因素建立:

时间轴表:

CREATE TABLE `activity_timer` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `time` datetime NOT NULL COMMENT '时间',
  `activity_id` int(11) DEFAULT NULL COMMENT '动态id',
  `timer_type` tinyint(3) DEFAULT NULL COMMENT '时间轴类型 (主时间轴,个人时间轴,热点时间轴)',
  `timer_rel` varchar(32) DEFAULT NULL COMMENT '时间轴关联对象',
  PRIMARY KEY (`id`),
  KEY `type_rel` (`timer_type`,`timer_rel`)
) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8mb4 COMMENT='时间轴表';

对于朋友圈扩展的热点:

CREATE TABLE `activity_hot_spot` (
  `id` int(8) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `hot_spot` varchar(10) NOT NULL DEFAULT '' COMMENT '热点',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `UN_HOT_SPOT` (`hot_spot`) USING HASH
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COMMENT = "热点";

热点模糊查询优化:

CREATE TABLE `activity_hot_spot_index` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `index_info` varchar(20) DEFAULT NULL COMMENT '索引字段',
  `hot_spot_id` int(11) DEFAULT NULL COMMENT '索引id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8mb4 COMMENT='热点索引表';

在此相关表设计完. 接下来就是流程设计

并不是很详细 以后补全 .

这块是设计思想,不是实际实现路线,

这边App那边是Java + kotlin 混合编写,而且对app缓存玩的不是很好,所以所有压力都塞给服务器.所以没有读取本地缓存这个步骤,所以缓存只有后端redis缓存