登录
首页 >  数据库 >  MySQL

千万级消息设计--初级篇(二)

来源:SegmentFault

时间:2023-02-16 15:44:37 400浏览 收藏

来到golang学习网的大家,相信都是编程学习爱好者,希望在这里学习数据库相关编程知识。下面本篇文章就来带大家聊聊《千万级消息设计--初级篇(二)》,介绍一下MySQL、Redis、缓存、mongodb,希望对大家的知识积累有所帮助,助力实战开发!

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_messagesys_message
  • 将sys_message中有效时间内的消息同步或更新到redis列表 message:sysmessags:init (原始系统队列)

        通过初始化自己的项目时,进行同步数据;通过定时程序同步更新数据库和redis中的数据。
  • 当用户在客户端和服务器交互的时候,触发(消息处理)检测用户是否拥有当前有效的系统消息;
    存在:不处理消息(可以判断个数);
    不存在:需要添加并且更新数据库或mongo;

        《原始系统队列》与《用户系统消息队列》对比个数,判断是否用户系统消息队列少了部分数据。
        少的部分,需要更新《用户系统消息队列》并且添加新的系统消息到**用户的个人消息表**
  • 消息未读数:使用redis,key - value 的形式存储一个用户未读消息个数数字;维护未读消息,需要在用户更新消息状态和给用户插入消息的时候,需要对未读数进行更新(为了未读数准确,可以进行特殊情况下更新未读数)
  • 列表暂时查询数据库等数据落地库。

原则

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

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

本篇关于《千万级消息设计--初级篇(二)》的介绍就到此结束啦,但是学无止境,想要了解学习更多关于数据库的相关知识,请关注golang学习网公众号!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>