在使用InnoDB memcached插件时,可能会因使用delete()方法而丢失未提交的数据
总结
在InnoDB memcached插件中,如果使用delete()方法来操作不存在的键,则可能会丢失未提交的数据。
前提
作为性能调整,假设同时增加了 daemon_memcached_r_batch_size 和 daemon_memcached_w_batch_size 的值。
参考链接:https://dev.mysql.com/doc/refman/5.6/ja/innodb-memcached-tuning.html
在这种情况下,如果系统崩溃了,未提交的数据丢失是可以理解的,但即使系统没有崩溃,也有可能丢失未提交的数据。
验证码
以下是在RDS for MySQL中的验证结果。
验证代码1:正确操作
<?php
define ("RDS_HOST_NAME", "******");
$memcache_obj = new Memcache;
$memcache_obj->addServer(RDS_HOST_NAME, 11211);
$memcache_obj->set("key1","value1", 0 ,10);
$memcache_obj->set("key2","value2", 0 ,10);
$memcache_obj->delete("key2"); // set()したキーを削除する
echo "rtn = ". $memcache_obj->get("key1")."\n";
→ rtn = value1 将被输出
key1的值无法获取,这是因为它刚被设置(set)。
<?php
define ("RDS_HOST_NAME", "******");
$memcache_obj = new Memcache;
$memcache_obj->addServer(RDS_HOST_NAME, 11211);
$memcache_obj->set("key1","value1", 0 ,10);
// $memcache_obj->set("key2","value2", 0 ,10);
$memcache_obj->delete("key2"); // set()していないキーを削除する
echo "rtn = ". $memcache_obj->get("key1")."\n";
返回值是“が出力される”。
对策 (duì cè)
需要采取以下其中一项对策
- 将 daemon_memcached_r_batch_size 和 daemon_memcached_w_batch_size 的值设为1。不使用 delete() 方法,而是在1秒钟内使用 set() 方法表示已删除的数据。
※2. 对于在null的情况下插入空值的情况,需要进行与明确缓存空值模式的验证。
【附言】作为会话存储,我希望使用InnoDB memcached插件的原因。
简而言之,它可以方便地准备具有一定可靠性的会话存储。
如果想将常规的Memcached用作会话存储,冗余支持就变得困难了。参考:http://qiita.com/taruhachi/items/a844bf373623991873ff
好处 chù)
-
- MultiAZ環境であればノード障害時に自動フェイルオーバーが実行される
-
- スケールアップ、スケールイン時にキャッシュが揮発しない
-
- 能力を超えたスパイク時にもレイテンシが低下するだけで、深刻な障害に直結しにくい
- memcachedプロトコルを利用可能なので開発環境を整えやすい
缺点 (quē
-
- スケール変更時に若干のダウンタイムが発生する
-
- 自動でのスケール変更ができない
- memcachedと比較した場合にはコストパフォーマンスが悪い
与其他会话存储的对比
該当のキャッシュの汚染が発生する自動フェイルオーバー実行自動フェイルオーバー実行自動フェイルオーバー実行性能上限比較的高速比較的高速比較的高速スケールアップの上限ありオートスケール出来ない出来ない出来る出来ないスケール変更時のデータ担保”該当キャッシュが揮発する
該当のキャッシュの汚染が発生するキャッシュが全て揮発する影響が発生しない影響が発生しないスケール変更時の挙動そもそもデータが担保されないそもそもデータが担保されないダウンタイムが発生しないダウンタイムが発生する(数十秒)メンテナンスウインドウあり(キャッシュが揮発する)あり(キャッシュが揮発しない)あり(キャッシュが揮発しない)あり(キャッシュが揮発しない)スパイク時の挙動レイテンシが低下するレイテンシが低下するキャパシティユニットの追加が完了するまでの間、スロットルされた以上のリクエストに対してエラーが発生するレイテンシが低下する特記事項(メリット)memcachedプロトコルを利用可能
使用頻度が低い時に低コストmemcachedプロトコルを利用可能特記事項(デメリット)高負荷時にはノード間のデータ汚染はかなりの頻度で発生する。スケール変更ができないので、高コストになりがちである。・独自プロトコルであるため変更しにくい
・使用頻度が高い時に高コストである
・一度パーティション分割が進んでしまうと、その後恒常的にスロットルが発生し始めることがある。del()利用時にロールバックされる。
同時接続数を1024より増やせない。
永続的接続時に接続の切断が発生する。
尽管在成本效益方面存在劣势,但从可伸缩性和数据保障方面来看,似乎也有许多优点。
补充记录
构建了应用程序并进行了负载测试,发现了两个问题。
請問第一個問題是什麼?
当利用永久连接时,与服务器的连接频繁断开。(可能根本就没有持久化吗?)
2號問題
隨著逐步增加負荷,開始頻繁出現「MemcachePool::set():Server [主機名] (tcp 11211, udp 0) 失敗:連接被拒絕(111)」這個錯誤。
由於是連接相關的錯誤,我試圖更改MAX_SIMULTANEOUS_CONNECTIONS,然而在RDS中,這個值只能在10到1024的範圍內設定。