python实现即时通讯后端思路整理

公司同事写的即时通讯系统，感觉他数据库设计的不合理，所以我准备模拟一下场景，自己设计一下架构，如果继续闲着，就弄个git项目，验证所学。

一、后端数据存储的选择
本来想使用redis或者mongodb，但是：
1.redis功能太少，如果用redis，还需要更多的学习成本，学习一些类似这样的工具：

RediSearch，高性能的全文搜索引擎（Faster, in-memory, highly available full text search），可作为Redis
Module运行在Redis上。但是它与其他Redis搜索库不同的是，它不使用Redis内部数据结构，例如：集合、排序集（ps.后面会写一篇基于Redis的数据结构来设计搜索引擎），Redis原声的搜索还是有很大的局限性，简单的分词搜索是可以满足，但是应用到复杂的场景就不太适合。

2.mongodb吧，也挺好，但是和我设想下的场景有点冲突：
我的模型设计下，mongo需要不断的追加子级进入父级，没找到这个的解决办法，也就是没找到相关的语句，也就不了了之了，如果有人知道如何实现，那请评论告诉我一下关键词，我自己百度学习一下。
3.所以，数据库就用mysql好了，可以使用redis缓存再保存到mysql，也是可以的，我在这里偷懒一下，就直接使用mysql了。

二、通讯机制
即时通讯肯定要用websocket，但是这里可以这样实现：
每个用户，都和服务器保持一个websocket，作为消息系统，其他任何操作，都走短链接。
比如用户在群里发送一条信息，这时候服务器接受http的请求，这个借口就调用websocket，给每一个需要接受信息的人，发送消息，信息里面封装这条信息的具体内容及发送人是谁、在哪个群里面发送的，这样的信息。
其他的比如登录、用户信息展示，这种可以直接使用http+html常规实现。

三、数据库结构设计

1.消息发布表
自增id
内容content
消息类型type
发布人

2.群表：
这个分两种群，初始群和普通群：
创建一个群聊，就是一个初始群；
然后，每次发生人员变动，就产生一个普通群；
这个初始群作为普通群的外键。
这样做的好处就是：初始群管理群文件、群公告、群相册等内容，就是常规中所见的群；而普通群，管理人员及观看权限等，因为人而产生的不同。
自增id
群名
群图标
初始群id

3.人：
id
name
头像url

4.群-成员对照表：
群id
人id

5.消息接收表：
对话时，引用或分享对话产生的数据，也整理在这里
id
消息发布id
接收对象类型：群、别人、自己
接收对象外键：群-外键、member-外键

这样，可以实现清晰的面向对象。按照：人、人群（根据面向对象的不同，分为初始群和普通群）、消息（一发多收，所以分表为发送表、接收表两个表），这样的规划，进行数据存储。

四、技术选择

1.python后端选择flask

2.调用flask_socketio或者flask_sockets这两个库实现websocket

3.数据库对接，使用SQLAlchemy库

4.序列化使用marshmallow库

这样可以实现解耦，方便后期更换模块。