memcachedと組み合わせたnoSQL（mongoDB）を使用して、Webアプリケーションにセッションを保存することを考えています。ページが読み込まれるたびに、ユーザーデータがmemcache内のデータと比較され、何かが変更された場合、データはmemcachedとmySQLの両方に書き込まれるという考え方です。このようにして、読み取りが大幅に削減され、memcachedが最善を尽くすために利用されます。
ただし、特にmemcachedレイヤーで、セッションストレージに非ACIDデータベースを使用することについて少し心配しています。DBへのセッションを更新しているときに問題が発生し、ユーザーがカートに入れた製品が表示されないのはなぜかとすぐに頭が痛くなったとしましょう...
これに対する適切なアプローチは何ですか？mySQLセッションストレージを使用する必要がありますか、それともセッション用に非酸性のサポートデータベースを保持するのは問題ありませんか？
ありがとう！
現在、セッションストレージとしてMongoDBを使用しています。pilifが言及する競合状態を回避することは可能です。MongoDBのセッションハンドラーを実装するクラス（http://www.jqueryin.com/projects/mongo-session/）を見つけ、ニーズに合わせてgithubでフォークしました（http://github.com/halfdan/MongoSession）。
セッションをロックせずに、保存する内容に本当に注意してください。読み取りと書き込みの間でデータが変わる可能性があるため、以前に読み取った内容に依存するものは絶対に保存しないでください。特に、複数のリクエストが同時に送信される可能性があるajaxの場合はそうです。
ロックされていないセッションに保存してはならない例としては、ショッピングカートがあります。これは、商品を追加するには、読み取り、シリアル化解除、商品の追加を行ってから、再度シリアル化する必要があるためです。他のリクエストが最初のリクエストの読み取りと書き込みの間に同じことを行う場合、2番目のリクエストのデータは失われます。
詳細については、この記事をご覧ください：http: //thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/
セッションをファイルシステム（PHPがロックする場所）またはデータベース（手動ロックを行う必要がある場所）に保持するか、その値が以前の読み取りから派生している場合は、セッションに値を書き込まないでください。
memcachedをデータベースのキャッシュとして使用する場合、データベースとキャッシュ間のデータの一貫性を確保する必要があるのはユーザーです。スケールアップしてサーバーを追加したい場合は、すべてが正常に見えても、データベースと同期していない可能性があります。
代わりに、Hazelcastを検討することもできます。1.9以降、memcacheプロトコルもサポートしています。memcachedと比較すると、HazelcastはMap Persisterを実装することを望んでおり、更新されたエントリのデータベースを更新するのはそれ自体だけです。このようにして、「データがデータベースを更新した場合にキャッシュをチェックする」ようなものを処理する必要はありません。
ユーザーがすべてのセッション情報をクライアント側に保存するようにアプリを作成する場合は、必要に応じてその情報を確認するだけで、サーバー側のセッションについて心配する必要はありません。これは、RESTスタイルのアーキテクチャの原則の1つです。たとえば、ユーザーがショッピングカートに商品を追加することをリクエストしている場合は、itemIDリストを保存し、クライアント側でカウントします。カートページにアクセスすると、カートに入っていることを示しているitemIDのリストからアイテム情報を簡単に検索できます。
チェックアウト中に、トランザクションを含むデータベースに直接アクセスして、競合状態が発生していないことを確認し、ライブインベントリを確認します。チェックアウト時に在庫がない場合は、「申し訳ありませんが、売り切れました」と言ってください。もちろん、その時点で、在庫があることを人々に伝えているキャッシュを更新する必要があります。
データを失いたくない場合は、ACIDでテストされたデータベースを使用してください。
あなたが探している見返りは何ですか？
安全なシステムが必要な場合は、ユーザーから何も信頼できず、おそらく選択された整数を除いて、情報を保存させることは通常、非常に悪い考えです。
MySQLデータベースの外部にセッションを保存することの見返りはわかりません。それが懸念事項である場合は、テーブルのcronクリーンアップを実行できますが、なぜわざわざするのでしょうか。一部のユーザーは、サイトで買い物をした後、しばらく気が散るでしょう。その後、彼らは1、2日後に戻ってきます。
クッキーなどを使用してセッション情報を保存する場合、買い物時間が無駄になる可能性が非常に高くなります。ユーザーは自分の時間を本当に大切にしています...したがって、セッション情報をデータベースに保存すると、そのデータを管理するためのセクシーなものを書くことができます。
さらに、これの良い副作用は、後であなたがおそらく利用できないであろうあなたのウェブサイトで人々が好きなものについての多くの残余情報を生成することです。あなたがそれのいくつかを世論調査のように考えることができるように、または人々が彼らのカートに追加しているアイテムがあなたのビジネスを管理する方法、在庫を注文する方法、またはあなたのマーケティングに集中する方法に影響を与える可能性があります。
あなたが本当に一時的な何かで行くならば、あなたは残りの利益を得ることに負けます。
ユーザーが取得するのにどれくらいの費用がかかるかを見てから、本当に良いシステムを実装するための費用はどれくらいかを尋ねます。ユーザーは生物学的な再試行方法であることに注意してください。「私は退屈しています...もう一度リロードを押してください...」これは最も完璧な解決策ではありませんが、「何も失わない-これまで」のコスト比較に対して許容できる場合があります。
追加のセキュリティが必要な場合は、セッションを別のmemcacheサーバーのセットにキャッシュして、偶発的なフラッシュが発生しないようにすることができます。:)
他にも多くのシステムmembase.orgと、ストレージをディスクに永続化する他の永続的なmemcacheソリューション（Java実装）がいくつかあります。クライアントを多少変更したい場合、またはmemcacheにアクセスする方法を変更したい場合は、memcacheセッションオブジェクトの独自のレプリケーションを実行できます。
-ダニエル