slack通知本地服务器_为什么企业聊天应用程序不能建立在服务器端数据库（例如环聊，Slack和Hip聊天）上？...

slack通知本地服务器

Those big players come into play where there requires team collaboration. The big players are built on a server-side database where the messages shared from one device to another is stored in their server database. Ultimately, this results in storing a huge amount of data within the server-side database (Cloud-database).
在需要团队合作的地方，那些大公司发挥作用。 大型企业建立在服务器端数据库上，从一台设备共享到另一台设备的消息存储在服务器数据库中。 最终，这导致在服务器端数据库(云数据库)中存储大量数据。
The consumption of cloud storage will be pretty high. The client-side database is more efficient where the messages relayed is stored in the client device. The messages will be queued to minimize the consumption of data in the server.
云存储的消耗将非常高。 客户端数据库在中继的消息存储在客户端设备中时效率更高。 消息将排队，以最大程度地减少服务器中的数据消耗。

To make it more interesting, let’s get onto a brief understanding of chat-functionality on a server-side database and client-side database.
为了使它更加有趣，让我们简要了解服务器端数据库和客户端数据库上的聊天功能。

聊天功能 (Chat Functionality)

服务器端数据库 (Server-side database)

• A single token key is carried to transmit messages from the client to the server.
  携带单个令牌密钥以将消息从客户端传输到服务器。
• The script runs on the server instead of the client-server.
  该脚本在服务器而不是客户端服务器上运行。

客户端数据库 (Client-side database)

• Transmission of messages from the server to the client is carried by accessing token keys.
  从服务器到客户端的消息传输是通过访问令牌密钥进行的。
• The client-server sends a request to multiple servers to access the message with the help of the token key available on the client-side.
  客户端服务器通过客户端可用的令牌密钥向多个服务器发送请求以访问消息。

As said that, in a group chat application, the number of messages relayed between the server and client is large, message queuing will be one of the most destructive issues. To handle the message queuing in the servers, MUC & PubSup was introduced to handle the multi-user messaging. MUC (Multi-user Chat) XMPP protocol designed for multiple users to communicate simultaneously and PubSup for senders to send messages directly to receivers.
可以这么说，在群聊应用程序中，在服务器和客户端之间中继的消息数量很大，消息排队将是最具破坏性的问题之一。 为了处理服务器中的消息队列，引入了MUC和PubSup来处理多用户消息传递。 MUC(多用户聊天)XMPP协议设计用于多个用户同时通信，PubSup用于发件人将消息直接发送给收件人。

MirrorFly, an
MirrorFly是一种 enterprise messaging solution uses the most versatile servers PubSup and MUC component to handle the concurrent users within a group chat or channel or even community. 企业消息传递解决方案，它使用功能最广泛的服务器PubSup和MUC组件来处理群聊，频道甚至社区中的并发用户。
Let’s see how MirrorFly uses the servers to handle the concurrent user base in real-time chat server that includes group, channel and Community chats.
让我们看看MirrorFly如何使用服务器处理包括群组，频道和社区聊天在内的实时聊天服务器中的并发用户群。

MirrorFly如何使用MUC和PubSup服务器一次处理数百万条消息？ (How MirrorFly Uses MUC and PubSup Servers To Handle Millions of Messages At a Time?)

• Relying on both MUC and PubSup servers, the MUC component takes control of the entire accessibility and administration for the user count of about 1000+ members in a group and community chat.
  依靠MUC和PubSup服务器，MUC组件可以控制整个可访问性和管理，而在群组和社区聊天中，约有1000多个成员。
• It provides the users of the community, group chat to create any number of channels where the concurrent user base doesn’t cross 1000+ users.
  它为社区的用户提供了群组聊天，以创建任意数量的频道，其中并发用户群不超过1000个以上的用户。
• On the line of security standard, the MUC component provides maximum security against data breaches when the user base limit is under 1 lakh.
  根据安全标准，当用户群限制在10万以下时，MUC组件可提供最大的安全性，防止数据泄露。
• The MUC component losses its potential when the user base crosses 1 lakh where all the chat groups turn into being an open community from the invite-only mode.
  当用户群超过10万，所有聊天组从“仅邀请”模式变为开放社区时，MUC组件就会失去其潜力。
• If the user base crosses 1 Lakh, MirrorFly infrastructure ensures to avail the PubSup server on real-time chat infrastructure to rely on messages from MirrorFly server to client-server.
  如果用户群超过10万，则MirrorFly基础结构确保利用实时聊天基础结构上的PubSup服务器来依赖从MirrorFly服务器到客户端服务器的消息。
• PubSup stores the data (messages) on the client-server (client device eg. mobile or desktop) which is accessible only by client token key. This operation takes place when the users’ device is in offline mode.
  PubSup将数据(消息)存储在只能通过客户端令牌密钥访问的客户端服务器(客户端设备，例如移动设备或台式机)上。 当用户设备处于离线模式时，将执行此操作。
• Thus, the content (messages) stored on the client-server is protected against any unauthorized access through the token key.
  因此，保护​​了存储在客户端-服务器上的内容(消息)免受通过令牌密钥的任何未经授权的访问。

底线 (Bottom line)

The chat infrastructure on every web and mobile application are designed on different servers, it depends on the application needs. Opting for client-side server-based (on-premises hosting) chat infrastructure over cloud server-based chat application has more effectiveness in securing and handling the messages when the user base crosses in lakhs. Thus, the demand over on-premises hosting of chat application has its own value for enterprises and businesses who wish to build or integrate collaborative (chat) platform into your web or mobile applications to handle million+ conversations.
每个Web和移动应用程序上的聊天基础结构都在不同的服务器上设计，这取决于应用程序的需求。 当用户群超过10万人时，选择基于客户端服务器的(本地托管)聊天基础结构而不是基于云服务器的聊天应用程序在保护和处理消息方面更具有效性。 因此，对于希望将协作(聊天)平台构建或集成到您的Web或移动应用程序中以处理超过100万次对话的企业，对聊天应用程序的本地托管的需求具有其自身的价值。

翻译自: https://habr.com/en/post/493868/

slack通知本地服务器