我的申请表如下：

>多个(< 20)设备客户端(Android)在单个位置运行.
>存在数千个位置(因此存在数十或数十万个设备客户端).
>还存在与每个位置的数据及其设备客户端同步的Web门户客户端.
>设备上生成的新数据通过REST API(ASP.net WebAPI)发布到服务器(云).

到目前为止,该应用程序是一个非常标准的应用程序,具有移动设备客户端和Web门户客

但是,由于每个设备客户端的要求不受我的控制(设备客户端需要在脱机模式下运行,减少网络延迟等),因此每个设备客户端都不使用服务器数据库作为其直接记录源.每个设备客户端都有自己的本地数据库(sqlite),该数据库与其所在位置的所有数据保持同步.例如：当我在设备客户端A上进行数据更改时,需要将该更改传播到设备客户端B和Web门户客户端C.

> Web门户客户端直接从服务器数据库读取,因为它不需要脱机功能.

正如您所看到的,这里的问题是我们现在需要一种方法来使所有设备客户端数据库实时保持同步.预期两个设备客户端之间的数据短暂延迟并且认为是可以的.

提出的解决方案

我提出的解决方案如下：

>当新的客户端设备最初联机时,它会收到自上次从服务器通过REST API上线以来错过的数据转储.
>通过REST API从客户端设备发布/更新/删除的每个新数据项都会传播到服务器数据库.服务器数据库包含所有位置的所有数据,应被视为永久记录源.
> Web门户直接与服务器数据库一起工作,因为它没有脱机类型要求.
>通过SignalR建立与每个客户端设备的连接到数据同步流服务.
>工作服务正在“拖尾”服务器数据库以进行新的创建/更新/删除操作.检测到CUD操作时,会为每个数据同步服务实例将消息分派到Azure Service Bus队列/订阅(通过扇出主题).这允许SignalR数据同步服务(使用Azure Service Bus背板)的水平扩展,因为将存在数千个设备客户端连接.
>数据同步服务从其消息队列/订阅中读取,并通过SignalR将同步消息(包含所有需要的同步数据)推送到所有连接的客户端设备(与数据相关的位置).

下图说明了此解决方案：

>大块描述服务器(灰色方块是可以水平缩放的HTTP Web服务器)
>箭头描绘了流经应用程序的数据的方向.

问题

> SignalR是解决此问题/解决方案的正确技术吗？最初我的解决方案涉及每个客户端设备建立自己的Azure Service Bus队列/订阅,该队列/订阅从数据库拖尾工作者(sync river)收集消息.该解决方案的问题在于,我会将大量浪费的消息推送到离线设备客户端,这些客户端可能不会在很长一段时间内重新联机,如果有的话.通过在设备客户端最初联机时转储增量数据,然后通过SignalR流式传输数据,我可以解决这个问题.
>之前我没有在生产环境中广泛使用SignalR,所以我对它有点新意.对于此解决方案,我可以期待遇到哪些问题/挑战？
>以下article指出“在某些情况下背板可能成为瓶颈.以下是一些典型的SignalR场景：高频实时(例如,实时游戏)：不建议在这种情况下使用背板.”这个解决方案会属于这一类吗？ Azure Service Bus消息的背板会引入哪些问题？如果不是这样,我还能如何扩展这个解决方案呢？

您也欢迎并赞赏您对此解决方案的一般意见和建议.