Part we introduced the architecture of this simple voice chat room, left two questions. First of all, the voice server is how to forward voice data?
We directly on the map. FIG dashed box connected to the same PBX. When speaking of A client will upload the voice data to the voice server A is connected; voice server queries other IP voice server where the user (BE) A room where the server room, divided into several situations: for the same server users B issued only voice data, to be forwarded to the appropriate server for voice users (CE) on the other server, the other server receives voice data forwarding, in accordance with the room information and sends them to the users in the same room.
There is a need to pay attention to detail, the room is an active server to synchronize the voice server room architecture . Because the voice service request is very large, if every time when they are forwarded schema information inquiry room, then the room server / database will become a bottleneck. Therefore voice server locally cached information architecture of the room (of course caching can lead to other problems, the future will be devoted). Cache synchronization mechanism uses the user into the active trigger the check-out and room server room server broadcasts regularly push the combination, can effectively ensure data consistency in network packet loss .
Another issue is whether the directory server a bit redundant? The answer is naturally negative. When the number of users in the same room is relatively small, the directory server may indeed be omitted, the client can obtain the IP address of a voice connection by DNS server to resolve domain names.
However, when the amount of users is very large, DNS slow refresh mechanism can not meet the rapid expansion and volume reduction. Directory Server also has an important role is to load balancing , compared to a simple DNS load balancing strategy manual configuration, add the directory server can achieve a more efficient complex balancing strategy. For example, to introduce the following points SET deployment.
上图展示了同一房间的用户连接语音服务器的两种分布：对于A-E用户散落在5台语音服务器，而A’-E’则连接到2台语音服务器。我们觉得，第二种分布更好。为什么？因为服务器数量更少，语音服务器之间的转发数据量更少。要知道在百万级甚至千万级别的语音服务系统中，机器成本和带宽成本是主要的成本。
如何实现第二种分布呢？这就有赖于目录服务器的负载均衡策略。其中一条策略是同一房间的用户优先分配到相同的语音服务器。当然还有其他的一些策略，我们先不展开。
除了通过负载均衡策略实现更聚集的分布以外，还有一种更常用的手段——分SET部署。如图所示，其实就是增加了一个虚拟SET的概念，一个SET是一个小的服务器集群。SET之间互相隔离，对于小房间（大房间后面再讨论），一个房间只能分布在一个SET内。
这样做有什么好处呢？首先，分SET部署天然可以实现同一房间用户的聚集分布。一个SET一般是10台语音服务器，如果按照单台能承载2万用户来计算，对于房间容量在20万以下的小房间，同一房间的用户都分布到一个SET上。其次，分SET部署更便于版本发布和日常运维。试想一下，同样是有几百台机器的语音服务器集群，分SET发布更新和不分SET发布更新哪个更容易？
增加SET以后，房间的架构信息增加了SET和房间的映射关系：
SET被赋予一组房间的概念，同一个SET内的房间类型可以多种多样，但是一般还是把同类型的房间放在一个SET，因为这样便于管理，发布更新也会比较简单。通常新扩容一个SET的时候，我们会设置SET的一些属性，例如这个SET只支持游戏开黑，那后续游戏开黑的新房间就会分配到这个SET。SET的扩容缩容和房间的新建和销毁我们将在后面的文章中具体介绍。
简单总结一下，本篇主要解答了上篇文章提到的两个问题：语音服务器之间是平行转发数据的；目录服务器除了有路由的功能还可以实现复杂高效的负载均衡策略。而从目录服务器的功能又引出了业界常用的分SET部署的概念。本文介绍的都是一些比较基础的概念，主要为后面的内容做铺垫。