千万级消息设计--初级篇（二）

说明

本文都是参加工作的实际情况,希望对大家有所帮助。—— 蚂蚁爬树不怕高，有心学习不怕老。

需求

1.用户个人消息，平台消息（平台给所有人发送消息）。
2.用户未读消息展示，消息列表展示

初期mysql数据库表设计：

1.用户信息表users_message

CREATE TABLE `users_message` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(200) DEFAULT NULL,
`content` varchar(4000) DEFAULT NULL,
`uid` int(11) DEFAULT NULL,
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`msg_type` tinyint(4) DEFAULT '1' COMMENT '用户消息为1, 系统消息为 0',
`is_read` tinyint(4) DEFAULT '0' COMMENT '是否已读0未读1已读',
`ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '操作更新时间【不由程序控制，由mysql系统控制】',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

2.平台信息表sys_message

CREATE TABLE `sys_message` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(20) DEFAULT NULL,
  `content` varchar(500) DEFAULT NULL,
  `create_time` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
  `msg_type` tinyint(4) DEFAULT NULL COMMENT '系统消息默认为0',
  `start_time` datetime DEFAULT NULL COMMENT '消息有效时间（开始时间）',
  `end_time` datetime DEFAULT NULL COMMENT '消息失效时间（结束时间）',
  `ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '操作更新时间【不由程序控制，由mysql系统控制】',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT COMMENT='平台的系统消息|通知';

名词

1.用户个人消息:平台中用户的个人普通消息(存储在users_message)。
2.用户系统消息：平台给所有用户发送的 系统消息(存储在users_message)。
3.系统消息：平台给所有用户发送的 系统消息（存储在sys_message）。
4.message:sysmessags:init (原始系统队列) 存放数据库中的sys_message的有效消息（定期需要更新）
5.message:user_sysmessage:compare（用户系统消息队列） 存储 用户与系统消息的关系（建议存储 用户唯一标识和系统消息的唯一标识）对应的时候数据库的关系表

操作思路

1.用户的消息：当平台给用户发送用户消息，直接在users_message添加一条记录。
2.平台消息：当平台给用户发送系统消息时，在sys_message添加一条系统消息记录。
3.每个平台都会有活跃用户和僵尸用户或不活跃用户。所以系统消息的发送，不会给所有人都发送。
原因：如果平台用户量较大时，假如100万，发一条系统消息，将要给100万的人发送一条，就是100w的消息记录。如果当系统消息堆积到20条，将会2000w用户系统消息，对数据库都是一个不小的压力。当数据量大时，查询，添加等操作都会变的异常慢
4.采取大家常用的处理方式：
1）使用中间表，存储用户的系统消息关系；如果系统消息关系表中没有（系统消息和用户的关系），添加关系，将系统消息插入到用户到用户消息表变为用户系统消息；存在则不做操作。请查看单系统站内信设计概述
2) 使用mongo等，存储用户的消息，也类似上述一样。请自己查阅资料...
我想说说自己的想法:上述的结构等，我在公司都尝试过，但是效果在特殊场合会出现弊端。思路大致为：（数据存储优化 + 业务逻辑优化）

数据存储优化 + 业务逻辑优化

1. 表结构不变，上述中的中间表，我们使用redis替换。
2. redis缓存记录不存在，插入数据，更新redis缓存。
3. 未读消息个数也使用redis缓存，不需要每次都去查询数据库或mongo(主要取决你的落地数据存储在数据库还是mongo)
4. 消息列表查询，是否每次都查询数据库或mongo,再考虑是否放入redis缓存。（续实践后，再分享给大家）

详解思路

• 两张表 users_message 和 sys_message
• 将sys_message中有效时间内的消息同步或更新到redis列表 message:sysmessags:init (原始系统队列)

        通过初始化自己的项目时，进行同步数据；通过定时程序同步更新数据库和redis中的数据。

• 当用户在客户端和服务器交互的时候，触发（消息处理）检测用户是否拥有当前有效的系统消息；
  存在：不处理消息（可以判断个数）;
  不存在：需要添加并且更新数据库或mongo;

        《原始系统队列》与《用户系统消息队列》对比个数，判断是否用户系统消息队列少了部分数据。
        少的部分，需要更新《用户系统消息队列》并且添加新的系统消息到**用户的个人消息表**

• 消息未读数：使用redis，key - value 的形式存储一个用户未读消息个数数字；维护未读消息，需要在用户更新消息状态和给用户插入消息的时候，需要对未读数进行更新（为了未读数准确，可以进行特殊情况下更新未读数）。
• 列表暂时查询数据库等数据落地库。

原则

• 能不使用数据库的就不使用，减少并发情况下，影响数据库的性能。
• 先做一个简单版，后续慢慢在自己的代码上的优化。
• 看看自己的情况，觉得选择自己的方案。
• 千万级的数据表，后期通过索引优化，结构优化，业务逻辑优化，避免大量并发查询。一般都不会出现问题

想详细的解释一下，可是语言真的好难组织哇。写着写着写成最终篇幅了。