ONLYOFFICE Enterprise Editionで作業するときに設定した主なタスクは、安定性を高めることでした。 Linux用のオフィスを開発する際にMonoは私たちを大いに助けてくれましたが（これについてはすでに少し書きました）、同時に多くの懸念を引き起こしました。 http Webサーバーの崩壊などの問題に関連していたのは彼でした。



もちろん、状況は最も快適なものではないため、安全にプレイし、1台ではなく2台のサーバーを起動することにしました。 通常モードでは、それらは並行して動作し、問題が始まるとお互いを保証します。一方が倒れ、もう一方が何が起こっているかについて完全な責任を負います。 しかし、ここではサーバーキャッシュの同期に問題があり、その解決のためにRedisが必要でした。



次に、Redisとの連携を始めた経緯とその結果について少し説明します。

仕組み

最初から始めましょう：ONLYOFFICEはnginx httpサーバーとfastcgi-mono-server4モジュールで実行され、.netアプリケーションを実行します。



ロードバランシングには、nginxモジュールngx_stream_upstream_moduleを使用します。これは、upstreamおよびfastcgi_passディレクティブを使用して次のように構成されます。

upstream fastcgi_backend { server 127.0.0.1:9000; server 127.0.0.1:9001; keepalive 64; } server { listen 80; location / { ... fastcgi_pass fastcgi_backend; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、2つのfastcgi-mono-server4サーバーがアドレス127.0.0.1:9000と127.0.0.1:9001で同時に起動し、nginx（彼に感謝！）輪になって負荷の分散を開始します。



この場合、すべての着信要求は2つのサーバーに均等に分散されます。最初の要求は最初のサーバーに送信され、2番目の要求は2番目のサーバーに、3番目は再び最初のサーバーに送信されます。



キャッシングは、作業を高速化するために使用されます。 キャッシュに、最も頻繁に使用されるデータを慎重に保存します。 これらには、たとえば、ユーザー、グループ、ユーザーグループメンバーシップの関係、アクセス権、ポータルリスト、サブスクリプションアラート、請求情報とクォータ、設定などが含まれます。

今、問題

上で述べたように、nginxはリクエストを異なるサーバーに円で分配します。 これと無料バージョンでは、セッションを特定のIPアドレス（ユーザー）に固定することができないため、キャッシュの不一致による多数のエラーが発生しました。



たとえば、ユーザーが最初から始めて、ポータルで名前を変更することにしました。 変更要求は最初のサーバーに送られ、そこでヒーローの新しい名前がデータベースに保存されました。 イベント情報は、最初のサーバーのキャッシュにもあります。 つまり、次の要求が2番目のサーバーに到着すると、彼は単に発生した変更を認識していないことがわかります。 ユーザーは再び古い名前を見て、新しい人生が始まっていないことを理解します。 これはすべて、2番目のサーバーのキャッシュ内の情報が変更されていないという事実によるものです。 もちろん、更新が行われ、2番目のサーバーはすべてを検出しますが、キャッシュがデータベースのデータと同期されてから数分後になります。

そしてここに彼は、Redisです

実際、この問題を解決するために、ONLYOFFICEサーバーの共有キャッシュとして機能するRedisプロジェクトを使用することにしました。 もちろん、ここでもいくつかの困難が生じました。 次に、どれをどのように克服したかを説明します。

主な困難

StackExchange.Redis Nugetパッケージの問題



何が悪かったのか ：Redisとの連携を選択したNugetパッケージStackExchange.Redisは、Monoとの連携を拒否しました。 インストール後、.netのアプリケーションを正常に起動しました。 モノラルでは、一定のエラーが発生しました：



redisサーバーに接続できませんでした。 切断されたマルチプレクサを作成するには、AbortOnConnectFailを無効にします。 pingでのソケット障害



彼らが決めたように、ここではすべてが簡単です。 Monoの下のソースからStackExchange.Redis.dllを収集しました。



ページの応答時間を増やす



何が問題だったのか ：多数のキャッシュアクセス（ユーザーリスト、グループ、アクセス権に関連するすべて）を含むページ、およびキャッシュされたデータがかなりの量を占めるページ（すべてのポータルのリスト）は、リクエストへの応答が遅くなり始めました。 それでも、それらのデータは別のプロセスのメモリまたは一般に別の物理マシンに保存され、ネットワークソケットを介してアクセスされます。これは、そのプロセスのメモリにアクセスするよりもはるかに低速です。



彼らが決めたように ：ヒット数とデータのサイズにとって重要なサイトでは、以前と同様にローカルキャッシュがありましたが、小さな通知システムをそこにねじ込みました。



このアルゴリズムによってキャッシュされたデータを変更するすべての方法で、publish / subscribe redisメカニズムを使用して、変更されたデータに関する情報を送信するコードを追加しました。 さらに、アラートを受信したすべてのサーバーは、示されたオブジェクトをデータベースと同期しました。



長時間の運用の問題



問題点 ：ユーザーがファイル操作を開始すると、キューに入れられたタスクが作成されます。 次に、前のタスクから解放されたスレッドが実行を開始します。 スレッドの数は、ファイル操作によるサーバーの過剰な負荷を回避するために上から制限されています（この機能はTaskSchedulerの特殊バージョンに基づいて実装されました）。



ファイルタスクの実行中、ユーザーは進行状況を表示し、タスクの完了時に成功またはエラーに関する情報を表示します。 これは、ドキュメントAPIモジュールを介してファイル操作のステータスを定期的にポーリングすることにより実装されますが、操作に関するすべての情報はローカルプロセスキャッシュに保存されました。 しかし、複数のONLYOFFICEサーバーが起動されると、操作のステータスに関するリクエストの一部が、現在のファイル操作が起動されたサーバーとは異なるサーバーに到達しました。 これにより、ユーザーの操作ステータスの表示にエラーが発生しました（タスクが突然表示または非表示になりました）。



決定通り ：分散タスクマネージャーを作成しました。 実行中のタスクのステータスをRedisに保存し、ワーカースレッドの数を制限し、サーバー間でタスクのステータスを同期し、完全に絶望的にハングしたものを削除します。



ちなみに、Microsoft.NET 4.0の標準System.Threading.Tasksをベースとして使用しました。



セッションプロバイダーの問題



問題点 ：Redisのセッションを承認することも決定し、Microsoft RedisセッションプロバイダーのネイティブRedisSessionStateProviderを選択しました。 実際には、Azureプラットフォーム用にMicrosoftによって使用およびサポートされているため、サーバーにインストールできますが、ご自身の危険とリスクがある場合に限ります。 判明したように、Windowsでも問題なく動作します。 しかし、Monoではそうではありません。ここではすぐに安定した動作に問題があり、小さな負荷でプロバイダーがNullReferenceExceptionでクラッシュしました。 サードパーティのプロバイダーを試すことにしました。 しかし、ここでは同じNullReferenceExceptionが発生しました。



決定通り ：セッションプロバイダーの内部構造と、ASP.NET for .NETでの処理がMonoとどのように異なるかを理解し始めました。 リクエストにCookieが含まれない場合、MonoのバージョンのセッションIDはnullになり、プロバイダーはそのようなキャッチを期待していません。 nullにセッションID検証を追加してpull-requestを作成しました。



2つのセッションプロバイダーのうち、サードパーティがより高速で軽量に思えたため、それを選択しました。 接続するには、Web.configの標準プロバイダーに置き換える必要がありました。

 <sessionState mode="Custom" customProvider="RedisSessionStateProvider"> <providers> <add name="RedisSessionStateProvider" type="RedisSessionProvider.RedisSessionStateStoreProvider, RedisSessionProvider" /> </providers> </sessionState>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、アプリケーションの開始時にいくつかのコードを追加する必要がありました。

 var configuration = RedisCachingSectionHandler.GetConfig(); RedisConnectionConfig.GetSERedisServerConfig = (HttpContextBase context) => { if (configuration.RedisHosts != null && configuration.RedisHosts.Count > 0) { var host = configuration.RedisHosts[0]; return new KeyValuePair<string, ConfigurationOptions>("DefaultConnection", ConfigurationOptions.Parse(String.Concat(host.Host, ":", host.CachePort))); } return new KeyValuePair<string, ConfigurationOptions>(); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まとめ

ここでは、完了した作業とその結果に満足していると簡単に言います。 Redisのおかげで、サーバーの復元力とスケーラビリティの両方を向上させることができました。これは、多数の（さらに絶えず成長している）ユーザーを想定している企業サーバーバージョンに不可欠です。



MonoをASP.Netの新しいクロスプラットフォームバージョンに置き換える予定です。 お互いを見ている間。