TCP の長い接続を直接使用します~~スマート ホームには通常、より多くの MQTT プロトコルが搭載されています~~
長い接続は、ポーリングよりも多くのリソースを節約します~
もちろん、データベースをカウントすることは別の問題です。

ここで分散アーキテクチャについてのあなたの理解をテストしたいと思います。この質問は 服务发现(service discovery)的认识。分布式就是把一个大型项目进行模块化拆分，然后各模块在做集群部署，前端有一个路由服务器来对到达的请求进行分发，把到达的请求路由到能够提供服务的服务端，而哪台服务器能够提供服务这就是服务发现所要做的事情，而在集群环境下能够提供相等服务的服务器肯定不止一台，那到底该由那台服务器对用户的请求进行处理并响应呢？这就又引出了负载均衡，由负载均衡层通过特定的算法来判断应该由那台服务器提供服务，目的就是均匀的把请求分发给各个服务端。服务发现可以了解下Apache的zookeeper或者Netflix的Eureka。微服务这块spring cloud提供了全套的解决方案，还有阿里的dubbo

分散セッション管理

私は簡単な計画を立てています
デバイスのエージェントプロセスをインストールします。デバイスの起動時にプロセスが開始され、一定期間報告されない場合、デバイスは定期的にデバイスの状態をアクティブに報告します。オフラインとみなされます

高い同時実行性、非同期通信。ジャワの言葉。 。 。 古典的なネット？
私の個人的な意見では、現在の単一マシンのパフォーマンスによれば、単一マシンで 100k の同時処理をサポートできます。もちろん、データベース ストレージを含める場合は別の問題になります。

長時間の接続を考慮しない場合は、redis を使用してデバイスごとにオンライン フラグを設定し、有効時間を設定し、クライアントがアップリンク リクエストを行うたびに有効時間を更新し、その数をカウントするという考えもあります。私は常にバックエンドで作業しているため、クライアントが非アクティブなときにどれくらいの時間オンラインを維持できるかがわかりません。デーモン？

データをredisに保存すると、dbよりもアクセスが高速になります

私だったら、これを実行します:
新しい MySQL メモリ テーブルを作成します (ENGINE=MEMORY):
online(user_id, update_time)
update_time を使用して、ユーザーの最新のアクセス時間を記録します。
たとえば、次のように仮定できます。 5 分以内にすべてのユーザーがオンラインだと考えます。

たとえば、100,000 台のマシンがそれぞれ 10 台のマシンにステータスを報告する場合、ハッシュ マッピングを使用すると、これらの 10 台のマシンが障害のあるマシンを報告します。状況を固定ホストに報告します。これは、おおよそ 10w->10-->1 を意味します。上記の例には単一障害点がある可能性がありますが、上位層のマシンの数を変更することで解決できます