Memcached的批量删除，向来是Memcached使用者很头疼的事情，因为Memcached采取的缓存方案是哈希表结构，所以没有办法实现delete from tablename where key like ‘%XX%’类似这样的批量删除功能。所以不得不自己采取一些策略实现批量删除。常见的删除方案主要有以下两种：
第一种方案：通过记录KEY到DB然后循环删除。
其实这也是最常规的删除方法，最容易想到，可能大部分人首先都会这么考虑。具体方法如下：
1. 添加业务数据时，在向Memcached缓存set数据的时候，将其key记录到数据库（或内存中，或文件中，由于数据量大，内存中基本不可行），也就是每set一条数据到Memcached缓存中，就向记录key的数据表（这类专门用于辅助删除缓存的表可以按业务分类建表，为了方便，我们下文简称keytable,因为不可能所有的key都用一张表，即使按业务分类建，数据量也是很庞大的）insert一条记录。数据表结构可以设计为这两个字段：key(对应缓存key), id(对应业务实体id)，这里的存储id主要是方便批量查询出需要从缓存删除的KEY时方便,也可以根据实际业务设计。
2. 删除业务数据时，首先从数据库的业务数据表删除数据，然后从keytable 中查询出keyList.查询语句类似，select key from keytable where 条件 ，再然后循环keyList从Memcached缓存中remove掉相应的记录，最后删除keytable表中相应的记录，删除语句类似delete key from keytable where 条件.
这种方法的优点：方案设计思路简单，符合常规思维，而且能达到精确删除的目的。
这种方法的缺点：删除代价比较高，需要数据库或其他存储介质辅助，而且实际应用中，缓存量是很大的，会导致大量频繁的对keytable表的insert操作，性能问题将会很严重，需要根据具体情况运用。
第二种方案:利用Memcached的LRU算法进行懒清理
这种方案主要是利用Memcached缓存根据LRU算法进行定期自动清理不用或少用的缓存，通过对key增加版本管理来实现。
该方案的具体方法如下（拿商品数据举例说明）：
1. 对缓存中的每个key进行版本管理，比如缓存商品数据的key为product_10001.0,这里的product表示商品这类业务数据，product_10001表示具体的商品对象10001，0表示版本号。
2. 在Memcached中维护一版本记录数据，这个很简单，比如整个系统只有商品，订单，用户这三类缓存数据，则在Memcached中只维护三个key，类似product_version,book_version,user_version.他们的取值范围为0-99之间循环，之所有循环是防止数据版本多了无限增大，管理麻烦，而且数字大了占用空间大（要对应到每个key的值）。
3. 删除商品数据时，首先从数据库删除对应商品数据的记录。然后更新对应商品的版本：product_version = product_version+1（记得当product_version=99时，product_version=0）。
4. 从Memcached中get数据时，需要get两次，首次按get对应业务数据的版本号，如product_version，然后根据数据本身的key+ 最新的product_version作为真正的key去取数据。这样删除了的数据自动为过期数据，Memcached会根据LRU算法清理。
5. 向Memcached中set数据时，也是先取最新的product_version，然后将数据本身的key+product_version作为key保存数据到缓存。
这种方案的优点：减少了批量删除从Memcached真正删除数据的麻烦。利用Memcached自身的特点解决删除问题，符合Memcached的设计思想。
这种方案的缺点：a.每次set数据都要，先get版本，然后set,性能上差不多降低了1倍，虽然性能方面还是不错。不过这个问题好像没有办法解决，原先考虑在客户端缓存版本，因为版本毕竟不是时时都变，但是考虑到版本数据时多进程间共享数据，所以不能这样做，每次必须从Memcached中取版本。否则难以保证是最新的。b.这种方案对内存上有点浪费，虽然Memcached会根据LRU算法清理低版本的垃圾数据，但是毕竟不是实时清理，所以必然浪费内存，所以内存不足的情况下，要仔细考虑采取此方案。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/chuan122345/archive/2010/01/05/5134509.aspx