有關類朋友圈設計(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快取

有關類朋友圈設計(3) -- 資料庫設計&現有技術&流程設計

有關類朋友圈設計(3) -- 資料庫設計&現有技術&流程設計

最新文章