真实情况是可怕的Memcached
首先
データアクセスの高速化、セッションの保持などに非常に重要なポジションを占めているMemcached
特徴をあげると、速い安い美味いで、AWS上のサービス化などされており、非常に扱いやすいプロダクトなのですが、Memcachedそのものが単一障害点とならないように冗長化を測った時に深刻な問題が発生する可能性があることをご存知でしょうか。
システムに心あたりがある方は今すぐ代替手段を検討しなければなりません。
如果您非常想使用Memcached，请点击这里。
如果你仍然想使用Memcached
前提条件 (Qian ti tiao jian)
-
- そもそも冗長化をしなければ問題ないという運用はその時点で怖いのでNG
-
- cache機構という性質上、データが飛ぶのは問題ない(”正”となるデータを他から読み出すだけ)が、誤ったデータが読み出されるのをNGとする
-
- Memcachedを利用した時に利用ノードを決定するのはMemcachedのクライアントライブラリの責任ですので、MemcachedそのものやElastiCacheなどのサービスとは無関係です。
- 障害時にキャッシュのミスヒットが発生することでシステム全体の負荷が増えてしまうという問題に関しては今回は触れていません。（※これもレプリケーション機構が動作していれば防ぐことはできますが、、、。）
Memcached有什么问题？
Memcachedではデータのレプリケーションを行えません。
そのため、ノードを複数利用した運用においては以下のケースにおいてデータ不整合を発生してしまいます。
1. 特定のノードに対して一時的なネットワーク障害などが発生する
2. 上記ノードに対してはデータの書き込みができないので、他のノードの中から生きているノード（以下、代替ノード）を利用してサービスを継続しようとする
3. 初回はデータが存在しないので、他のRDBなど”正”となるデータソースからデータを取得して、代替ノードにキャッシュを書き込む
4. 更新系のリクエストにより、RDB等のデータと同時に代替ノード上のデータ更新（もしくは削除）を行う。
5. 障害ノードが復旧する。
6. 障害ノード上のデータは更新前の古いデータが残っているため、データ不整合となる。
上述问题的发生频率和影响
在高负载时，连接到每个节点的请求失败是经常发生的。这不仅仅是因为节点完全失效，因此在某些生死监测系统中进行切换处理可能无法捕捉到此情况。在这种情况下，只是连接失败，并未删除原始节点的数据。※从形象上看，类似于在高负载时发生RDB连接失败，因此需要加入连接重试机制等。
また、更新前の古いデータがあった時にはそもそもRDB上の”正”のデータを参照しないのが普通なのでそれが古いデータであることは検知しにくいため、該当のリクエストに関しては深刻な障害を発生する可能性があります。
この障害はMemcachedにおいて設定したExpireや、新たなデータをセットするまで継続しますが、Memcached上のデータが正しいと仮定して構築されたシステムにおいては、その間違ったデータをRDBにコミットする元データとして扱ってしまったり、傷口をどんどん広げる可能性があります。
研究使用Memcached替代系统的可能性。
我们考虑了Redis和KyotoTycoon作为替代系统。
选择Redis的原因是因为它作为AWS的服务已经部署，因此对于已经使用ElastiCache的情况下，心理上的门槛较低。
(※造語)シングルマスタマルチスレイブマルチマスタ双方向レプリケーション速度Set/Getの速度、ただしベンチマークの内容や、ストレージへの保存ポリシーによって大きく変わってくるのであくまでも参考値高速
(ノードの追加により書き込み、読み込み共にスケールする)Memcachedとほぼ同等
(読み出しはスケールする)前者2つの半分程度？
(データ同期を行っていた場合は書き込みのスケールには限度があると考えられる。読み出しはある程度スケールしそう。)アトミック操作データのアトミック操作が可能かどうか△
casを実装○△
casを実装扱えるデータvalueとして扱えるデータの種別
(Redisはindexをkeyとは別に作ることにより、value側のデータを利用したアクセスも可能。)StringのみString
List
Set
Sorted Set
HashStringのみ一言評価memcachedのサービスを冗長化したい場合においての評価ElastiCacheとして提供されており、一時キャッシュの共有にはお手軽だが、冗長化したい場合はかなり注意が必要なので強くはお勧めしない。高機能なのでMySQLが苦手な一部集計機能などを担うには良いかもしれない。
しかし、MySQLの全機能の代替は非常に厳しそうなので、適材適所といったところか。
冗長化したい場合はRedis Sentinelを利用する必要があるが、復旧までの速度や運用しやすさなどは不明。
また、クライアント側に全面的に書き直しが必要。クライアント側の書き直しが不要なので、機能的にはMemcachedで十分だが、冗長化だけはしておきたい場合においてはこの中ではベストソリューションだと考えられる。
有关冗长化的方法及其各自的优缺点，请补充详细解释。
多主无从模式（memcached）
根据客户端库想要存储的数据的每个键，确定要存储的节点。
然而，当连接不可用时，从剩余的节点中确定。
优点
-
- マスタノードの追加とともに読み書き速度が上がる
-
- どれかのノードが生きていればとりあえずサービスは可能
- レプリケーション遅延に関しては一切考慮する必要がない
缺点
-
- 接続不能状態から元に戻ったタイミングで、古いデータにアクセスしてしまう。
- ※前述の通りこれは重大な問題でかつ、アプリケーション側は根本的な対策を取ることができない。
单主多从方式
MySQLのレプリケーションと同じく、書き込む対象のマスタノードは常にひとつで、複数のスレイブノードにレプリケーションを行う方式。
优点
-
- スレイブノードの追加とともに読み込み性能が上がる
- マスタノードの読み出し負荷を分散できる
デメリット
-
- このままではマスタノードが単一障害点なので、スレイブノードのマスタ昇格機能が必要(Redisの場合はRedisSentinelでサポート)
-
- 高速とはいえ、スレイブノードのデータはレプリケーション遅延があるという前提で利用しなければならない。
-
- 書き込みはマスタ、読み込みはスレイブといった割り切りはNG
-
- 書き込み性能をスケールアップすることができない
- Memcachedの単純な代替としては不適格
マルチマスタ双方向レプリケーション方式(KyotoTycoon)
マルチマスタノンスレイブ方式とほぼ同じであるが、マスタノード間でデータのレプリケーションを行なうことで対障害性をアップさせる方式
优点
-
- クライアント側のシステムはMemcachedと完全に同一のロジックで実装可能
-
- マスタノードが単一障害点とならない
-
- 通常時はスレイブノードを利用しないので、データの一貫性が担保される
-
- マスタノードの障害が発生してもデータの不整合が発生しにくい
- ある程度まではスケールしやすい
缺点
-
- ノード数が同じ時はMemcached利用時よりパフォーマンスが落ちる
-
- マスタノード障害発生直前に書き込んだデータはデータ不整合の対象となる可能性がある。
- データ書き込みが増えた場合にデータ書き込みのオーバヘッドが大きくなる。
补充1
如果您要从源代码安装memcached，也可以使用由KLab开发的repcached方法。根据此方法，最多可以设置两个节点，因此在需要较少的扩展性要求下，这是一个有效的选择。参考repcached的介绍pdf。
* 我们过去考虑过使用这个产品，但由于无法利用Memcached的线程支持，我们选择了不引入此问题。
继续记述2
实际上，我在近两年前第一次注意到这个问题时，是在整理与当时进行的调查有关的文章。因此，我忽略了新的产品。据说还有一个名为yrmcds的产品，是由Cybozu开发的。他们刚刚发布了yrmcds 1.0.0版本。它是一个与Memcached兼容的产品，可以在热备份服务器上进行复制，并在故障时自动升级。
