问题：针对不同客户的多个mirth连接安装的最佳服务器架构是什么？
详细问题：我们有一个客户端正在发送HL7消息以及其他数据与CSV文件。我们使用Mirth Connect将这些数据处理到我们的系统中（在Mirth Connect中使用大约7个通道）。 Mirth连接安装及其内部数据库位于同一服务器上。但是，在不久的将来，我们将增加许多客户端（今年大约10个），我们需要提出一个应该能够处理负载的可扩展解决方案。我们计划为所有mirth连接安装的内部数据库使用单个中央服务器（功能强大）（Postgresql db为每个mirth连接实例使用不同的模式）。每个客户端有一个mirth连接实例，每个实例都连接到一个连接到中央数据库服务器的独立（较小）服务器上
这是一个好方法吗？
提前谢谢。
答案 0 :(得分：0)
当然，您所描述的是一种可行的解决方案。如果所有服务器都连接到同一个内部数据库，则所有通道都将部署在所有服务器实例上。但是如果你为每个实例保持模式（总是觉得使用那个词很奇怪），那么你牺牲了可维护性，因为现在你有多个MC实例登录和管理。
仍然可以在单个数据库上执行您想要的操作...例如，通道A1..An应仅部署在客户端A的实例上，通道B1..Bn应仅部署在客户端实例上B等等。您可以做的一件事是使用全局部署脚本来检查您当前的服务器ID，并在您自己的自定义查找表中查找该服务器“允许”的通道。然后，如果不允许，则抛出异常，以便不部署通道。
还有一种混合方法。每个客户端仍然有一个单独的实例/数据库，但您也可以为每个客户端提供多个实例。您可以执行此操作以实现主/备用故障转移或主动/主动负载平衡目的。这样，您还可以在MC应用程序级别实现高可用性。这就是Advanced Clustering extension真正闪耀的地方......它是专为水平扩展共享单个共享数据库的MC实例而构建的（也可能是水平扩展的）。
总的来说，每当有人遇到性能/吞吐量问题时，绝大多数情况下瓶颈不是MC本身，而是磁盘I / O写入时间。所以我绝对建议在您的数据库存储层使用SSD。或者至少在旋转磁盘上的SSD快速缓存。