1. Requirements
The following functions of the live broadcast room need to be realized:
- Mass messaging (text, pictures, recommended products)
- Point-to-point private messaging (text, pictures, recommended products)
- Single user ban
- All users banned
- Withdraw message
- Persistent chat history
2. Technical realization
The server-side message center is implemented with netty,
micro-stations and applets use websocket to communicate with the message center, and the
Android terminal uses netty to communicate with the message center.
The server will push a ping message to the client every certain time. After receiving the ping message, the client replies to the pong message. The heartbeat verifies the surviving client, periodically disconnects the link to the non-replying pong message, and removes the server connection session information.
After the client disconnects the link due to network and other issues, the client needs to implement a regular reconnection mechanism, first set to try to reconnect every 5 seconds after disconnection, this time may be modified later.
Server link address: ws: // {ip}: {port} / websocket? LiveId = 123 & userId = 00b084ea98e24e80a7f8be3c4b8a64d0
liveId is live id, userId is user id
1. Message format The
message is a json format string with the following attributes:
| Field name | Types of | meaning | Whether the client is required |
|---|---|---|---|
| id | string | uuid, generated by the server | Not filled |
| LiveID | string | Live id | Required |
| code | int | System message type | Required |
| type | int | Business message type | Business message is required, but heartbeat message is not |
| msg | string | Message content | Required, heartbeat message is not filled |
| sendUserId | string | Sender user id | Required |
| send username | string | Sender username | Not filled, the server returns |
| sendUserHeadImg | string | Sender avatar | Not filled, the server returns |
| receiveUserId | string[] | Recipient user id array | code is not required for mass sending, private chat is required |
| send hour | string | Sending time, generated by the server, format: yyyy-MM-dd HH: mm: ss | Not filled |
| ext | string | Extended Information | Optional |
Message code definition
| code | meaning |
|---|---|
| 1 | peer to peer |
| 2 | Bulk |
| 3 | Ping message, server heartbeat sent to the client |
| 4 | pong message, the client responds to the pong message after receiving the ping message |
Message type definition
| type | meaning |
|---|---|
| 1001 | Plain text message |
| 1002 | Picture message |
| 1003 | Recommended product news |
| 1004 | Single user banned message |
| 1005 | All users banned messages |
| 1006 | Withdraw user's speaking message |
| 1007 | Reward news |
pong消息示例：
{
"code":4,
"liveId":"asfasda",
"sendUserId":"sfasdasdasd"
}
a. Examples of ordinary text messages:
{
"id": "fasdasdasd",
"liveId": "fasdasdas",
"code": 2,
"msg":
"Hello" , "sendUserId": "This is from the sender User id ",
" sendUserName ":" asfasdas ",
" sendUserHeadImg ":" fasdasdasdsad.jpg ",
" receiveUserId ":" This is the user id of the recipient ",
" type ": 1001,
" sendTime ": 133548798798,
" ext ":" {} "
}
b. Examples of ordinary text messages with emoticons:
{
"id": "fasdasdasd",
"liveId": "fasdasdas",
"code": 10001,
"msg":
"Hello [smile]", "sendUserId": "This is the user id of the sender",
"sendUserName": "asfasdas",
"sendUserHeadImg": "fasdasdasdsad.jpg",
"receiveUserId": "This is the user id of the recipient",
"type": 1,
"sendTime ": 133548798798,
" ext ":" {} "
}
Note: [smile] is the character string identifier of the smile emoticon picture. After receiving this message, the client needs to replace the emoticon identifier with the picture and display it in the chat window.
c. Picture message example:
first compress the picture file on the client side, try to control it to within 1M, and then call the upload picture interface to get the relative path of the picture. If the upload is successful, assemble the websocket message and put the path into msg:
{
"id": " fasdasd ",
" liveId ":" fasdasdas ",
" code ": 2,
" msg ":" / static / img / chat / 2020-02-11 / xxx.jpg ",
" sendUserId ":" This is from the sender User id ",
" sendUserName ":" asfasdas ",
" sendUserHeadImg ":" fasdasdasdsad.jpg ",
" receiveUserId ":" This is the user id of the recipient ",
" type ": 1002,
" sendTime ": 133548798798,
" ext ":" {} "
}
d. Recommended product message example:
The msg field of the recommended product is the product information json
{
"id": "asfasdsdads",
"liveId": "fasdasdas",
"code": 2,
"msg": "{" productId ":" asdasfas "," productType ": 1," originPrice ": 100," currentPrice ": 100," productName ":" sfasd "," coverImg ":" asfasdasd.jpg "}",
"sendUserId": "This is the sender User id ",
" sendUserName ":" asfasdas ",
" sendUserHeadImg ":" fasdasdasdsad.jpg ",
" receiveUserId ":" This is the user id of the recipient ",
" type ": 1003,
" sendTime ": 133548798798
}
e. Sample reward message:
{
"id": "fasdasd",
"liveId": "fasdasdas",
"code": 2,
"msg": "/ static / img / chat / 2020-02-11 / xxx. jpg ",
" sendUserId ":" This is the user id of the sender ",
" receiveUserId ":" ",
" type ": 1007,
" sendTime ": 133548798798,
" ext ":" {"name": "was rewarded User's username "," price ": 100}"
}
f. Example of a single user banned message:
{
“id”: ”fasdasd”,
“liveId”: ”fasdasdas”,
“code”: 2,
“msg”: “id of banned user”,
“sendUserId”: ” This is the sender's user id ",
" receiveUserId ":" This is the receiver's user id ",
" type ": 1004,
" sendTime ": 133548798798,
" ext ":" {'name': 'is forbidden Username '} ”
}
f. Example of single user unmute message:
{
“id”: ”fasdasd”,
“liveId”: ”fasdasdas”,
“code”: 2,
“msg”: “id of the user whose
mute was canceled”, “sendUserId” : "This is the user id of the sender",
"receiveUserId": "This is the user id of the sender",
"type": 1010,
"sendTime": 133548798798,
"ext": "{'name': 'is banned言 的 username '} ”
}
f. Example of withdrawal message:
{
"id": "fasdasd",
"liveId": "fasdasdas",
"code": 2,
"msg": "the message id that was revoked",
"sendUserId": "This is the sender User id ”,
“ receiveUserId ”:” This is the user id of the recipient ”,
“ type ”: 1006,
“ sendTime ”: 133548798798,
“ ext ”:” ”
}
2. Message interaction process
Steps to receive messages:
a. When the user opens the live introduction page, he initiates a connection establishment request to the registration center and listens for messages pushed by the message center.
b. When the message pushed by the message center triggers the monitoring event function, it is determined that the type is one of ordinary text messages, system messages, and recommended product messages, and then the corresponding logical processing and display are performed.
Send message steps:
a. When the user opens the live introduction page, he initiates a connection establishment request to the registration center and listens for messages pushed by the message center.
b. If it is a normal chat text message or system message, the message json is assembled according to the agreed message format. If it is a picture message, first call the picture upload interface to get the url and assemble the url into the message json, call websocket or netty sdk to the message center send messages.
Steps to withdraw message:
a. When the teaching assistant and ibos click to withdraw, assemble a message with type as withdrawal, code as group sending type, and msg field as the message id to be withdrawn, and send it to the message center.
b. After receiving this message, the message center changes the message status in mongodb to withdraw and broadcasts the withdrawn message to all clients.
c. After receiving the message, the broadcast client hides the corresponding message by message id.
Single user mute step
a. When the teaching assistant and ibos click on the user's mute, assemble a message whose type is mute, code is point-to-point private chat type, and msg field is the user id that needs to be mute, and send it to the message center.
b. After receiving this message, the message center will persist the user's mute state to the database, and record the relationship between the live broadcast and the user's mute in the cache. If the user's client still maintains a session connection, push the banned user's client peer-to-peer.
c. After the banned user client receives the message, the text box is disabled and the user is prompted to be banned.
Note:
When the user refreshes the page, the latest mute status will be obtained from the database and the text box will be disabled / enabled. In extreme cases, the user sends a message. When the message passes the message center, it will check whether there is a ban on the live broadcast user in the cache. If there is, the message will not be pushed.
The interactive steps to cancel a single user's mute are the same as the above steps, except that the type of the message is to cancel the mute.
Steps to mute all users
a. When the teaching assistant and ibos click all users' mute, the mute state of the live broadcast will be persisted to the database, and the mute state of the live broadcast will be recorded in the cache. Assemble a message whose type is all banned and code is broadcast, and send it to the message center.
b. The message center broadcasts the message to all clients watching the live broadcast.
c. After the client receives the message, the text box is disabled.
Note:
When the user refreshes the page, the latest live streaming ban status will be obtained from the database and the text box will be disabled / enabled. In extreme cases, the user sends a message. When the message passes through the message center, it will check whether there is a live streaming ban in the cache. If there is, the message will not be pushed.
The interactive steps to cancel the ban on all users are the same as the above steps, except that the message type is to cancel the ban on all users.
3. Message storage
A queue is added to the local memory of the server where the message center is located as a buffer, and the chat records passing through the message center are appended to the buffer. Enable the asynchronous task to regularly check whether the buffer reaches the threshold. After the buffer threshold is reached, it is stored in batches in the mongodb chat record table.
mongodb table structure
| Field name | meaning |
|---|---|
| id | Primary key |
| zbId | Live id |
| msgId | Message id |
| sendUserId | Sender id |
| receiveUserId | Recipient id, separated by multiple commas |
| send hour | Sending time |
| code | Message sending type |
| type | Message type |
| msg | Message content |
| ext | Message extension |
| createTime | save time |
4. Authentication
Verify the user's speech status in the message center.
5. Expansion
If you need to support hot deployment and expansion, you need to solve the following pits:
1. The client session management code of the message center needs to be transformed into distributed session management, such as using redis for storage, but when the number of connections is too large, the network request transmission The amount of data will also increase, inappropriate.
2. The cluster needs to solve the problem of load balancing. At present, only client load balancing can be done, and server load balancing cannot be achieved like nginx forwards http requests.
3. At present, there is no mature standard solution to solve the above problems on the market, you need to make some attempts by combining some scattered ideas.
The idea of the message service cluster found on the Internet:
If you consider the socket cluster from your own programming, then it is difficult. Tell you an architectural model that I have used.
1. HTTP services are clustered.
2. After the socket server is enabled, it directly accesses the HTTP service and actively informs that there is a new socket service. The socket service state is stored in the intermediate cache layer. The specific service state can be detected by HTTP heartbeat polling. This part is the active discovery and loading of the socket service Services, uninstall services.
3. The client requests the HTTP service. The HTTP service analyzes the survival status and load of each socket service stored on it, and then returns the optimal socket service address to the client.
4. After obtaining the socket service address of the optimal load, the client connects to the corresponding socket service.
5. For data exchange between services, a socket service can be added as a relay station for socket services. This method is not very reliable and strongly depends on the survival status of the relay service.
6. The data of each socket service must be able to ensure global sharing and be used for the commonality of data between the clients, so that the user feels like being completely connected to a socket service.
The next article is the code implementation for netty to implement message push: netty implements message center (2) build a chat room based on netty