Detailed design and implementation of instant messaging (PHP + GatewayWorker + Redis)
We need to implement functionality
- One chat (whisper)
- Chat-many (group chat)
- Similarly QQ, micro-letters and other real-time chat message listing
Tool selection
-
GatewayWorker has the following characteristics (See more network examiner manual)
- Based Workerman Development
- Based Gateway, Worker Process Model
- Support for distributed deployment
- Support high concurrency
- Support global broadcast or push data to any client
- Support a variety of application layer protocols
- Multi-Protocol Support
- Objects or resources to maintain a permanent support
- high performance
- Easy integration with other projects
- Support long connection
We mainly use it WebSocket protocol, and this framework is very convenient to use in conjunction with ThinkPHP, laravel and other frameworks, GatewayWorker can be deployed independently, php responsible for the relevant business logic
- Redis key operation, the set lists.
Instant messaging, the most important is the speed of response, we need to show the "Message List" So then there will be unread messages, the number of unread, the last message content, time and so on.
websocket and GatewayWorker principle will no longer use narrative, children's shoes, please do not understand the degree of your mother
Show results
Group chat | whisper renderings
Message List renderings
Database Design (group chat, private chat separately)
Whisper design (design brief)
| parameter name | Explanation |
|---|---|
| id | Primary key |
| sender_id | The sender id |
| receive_id | Receiver id |
| chat_identify | Identifying: a chat and b, b and a chat. Record ab |
| message_details | Message content |
| last_time_at | Chat recording interval exceeds a predetermined time |
- chat_identify field use, in this field in order to more easily find chats between a, b.
- last_time_at QQ, chats between the micro channel, the time intervals will be recorded, not the display time per one chats
Group Chat (design brief)
- And whisper like, but the receiver id, become group_id group id.
Message list design, expect to see the effect of a "private chat, group chat," and so in a list display, and data changes occur in real time. Here With Redis
Each user list is a collection of key = message_list: user_id
Redis集合存储 消息类型 1私信，2群聊
message_list:user_id{
json_encode(['消息类型','接收者id|群组id']),
json_encode(['消息类型','接收者id|群组id']),
json_encode(['消息类型','接收者id|群组id']),
}
查找每个人的消息列表，直接取出该列表即可，但每个成员 都要对应 ‘未读消息数量’，‘最后一条消息内容’，‘最后一条小时时间’。由于是可变的，所以需要单独存储
Redis 键值 key = message_content:user_id_消息类型_id
key =>json_encode(['消息数量','最后一条消息内容','时间'])
上面 集合列表里的每一个成员都 对应这里的每个键值。
- News update every operation Redis, the appropriate updates.
- There is no doubt the speed, redis quite quickly.
Subsequent optimization of local needs
-
Whisper | group chat records table. The current design is a single form library. Obviously, with the increase of users, the inevitable bursting. Affect the response speed of queries.
- (Solution nothing more than: sub-library sub-table, transfer backup history)
- GatewayWorker communications framework, is a single-server deployment, can not support high concurrency.