最近在項目中實踐了一下Redis,過程中遇到並解決了若干問題,記錄之.
Why Redis
我們這個項目是對原有緩存系統的改進,應用場景是論壇發帖,回帖,置頂,以及操作日志等等;原有系統會有替換算法把內存緩存一部分冷數據逐漸從內存中換出,內存對象序列化為XML文件持久化到磁盤;內存緩存一方面是為了訪問速度,一方面是為后端的DB分擔訪問壓力;而XML文件緩存則是為了避免雪崩,即當系統重啟的時候由於緩存沒有填充完畢,大量相同的請求會沖擊到后端的DB;最初接手項目的時候，被告知公司老大要求xml 文件緩存必須保留，呵呵，通過和老大溝通其實保留文件緩存就是為了解決雪崩.
我們這個項目是對原有緩存系統的改進,應用場景是論壇發帖,回帖,置頂,以及操作日志等等;原有系統會有替換算法把內存緩存一部分冷數據逐漸從內存中換出,內存對象序列化為XML文件持久化到磁盤;內存緩存一方面是為了訪問速度,一方面是為后端的DB分擔訪問壓力;而XML文件緩存則是為了避免雪崩,即當系統重啟的時候由於緩存沒有填充完畢,大量相同的請求會沖擊到后端的DB;最初接手項目的時候，被告知公司老大要求xml 文件緩存必須保留，呵呵，通過和老大溝通其實保留文件緩存就是為了解決雪崩.
原有系統的問題在什么地方？
了解原有系統的瓶頸是第一步，原有系統主要問題是：
了解原有系統的瓶頸是第一步，原有系統主要問題是：
[1] 操作粒度過大,訪問數加1這樣的操作都會導致整個DataSet數據對象的序列化和反序列化
[2] 由於DataSet本身就是一個復雜數據結構,一方面會占用更多內存,一方面序列化和反序列化都會更比簡單對象更耗時
[3] DataSet序列化XML,XML文件會有並發讀寫的問題,這里也是經常出現故障的點
這樣我們就能整理出來設計的要點了:
[1]提供內存緩存的服務
[2]要有持久化緩存,系統重啟之后,可以從持久化緩存加載到內存,避免雪崩
[3]要解決內存對象鎖和文件鎖的問題
[4]由於是從關系型DB讀過來的數據,數據之間的關聯關系是已經建立好的
新方案思考的起點是從數據操作粒度, 如果沿襲之前的方案,操作粒度是整個帖子+回帖+相關帖+操作日志的DataSet對象,對於只修改一兩個字段的場景成本太高;所以決定把數據操作的粒度縮小,首先把DataSet中的業務對象拆開這是第一步,這也是我們最起碼要做到的,拆分之后對象容器不再使用Dataset,我們把這種粒度稱為粒度①;這樣拆分之后,再一次縮小粒度,目標是把粒度控制為字段級別,這里的判斷依據就是業務邏輯,比如操作日志每一次讀寫都是一個對象,那么把它的讀寫粒度放在字段級別沒有多大好處;但是像主帖訪問次數+1這種,就很適合字段級別的粒度,我們把這種粒度稱為粒度②;Memcache可以很好的解決內存緩存的問題,但是存在的問題是:1.可以很容易做到支持粒度①,但是要做到粒度②需要構造維護對象的邏輯有點麻煩,與memcache交互的次數過多; 2.在這個基礎上還必須要實現持久化緩存的部分.
如果是NoSql呢?經過對比Redis可以取代原來的內存緩存和XML文件緩存:
[1]可以作為內存緩存使用
[2]數據可以持久化
[3]支持多種數據結構,可以實現操作粒度②
學習Redis
我的Redis的學習參考主要集中在:
- 官方網站 http://redis.io/
- Redis命令 http://redis.io/commands
- Redis協議 http://redis.io/topics/protocol
- NoSQLFan Redis資料匯總專題 http://blog.nosqlfan.com/html/3537.html
熟悉了命令之后,仔細閱讀了Redis協議,總結在[Erlang 0019]Redis協議解讀與實現(.Net & Erlang) ,通過協議的學習實際上有了一個心理底線:只要通過協議能夠實現的功能,我們就可以在Client實現.NoSQLFan上匯集了很多優秀的Redis資料,我專門預留了一部分時間閱讀上面的文章.
ServiceStack.Redis實踐
Redis的C#客戶端我選擇的是ServiceStack.Redis,相比Booksleeve redis-sharp等方案,它提供了一整套從Redis數據結構都強類型對象轉換的機制;看一個例子來了解一下ServiceStack.Redis是如何組織數據的,我們使用的實體類定義如下:
public class User
{
public User()
{
this.BlogIds = new List<long>();
}
public long Id { get; set; }
public string Name { get; set; }
public List<long> BlogIds { get; set; }
}
使用下面的代碼片段,我們存入兩條數據到Redis:
using (var redisUsers = redisClient.GetTypedClient<User>())
{
var ayende = new User { Id = redisUsers.GetNextSequence(), Name = "Oren Eini" };
var mythz = new User { Id = redisUsers.GetNextSequence(), Name = "Demis Bellot" };
redisUsers.Store(ayende);
redisUsers.Store(mythz);
}
我們看下Redis中的結果:
redis 127.0.0.1:6379[1]> keys *
1) "seq:User"
2) "ids:User"
3) "urn:user:1"
4) "urn:user:2"
我們逐一檢查一下數據類型:
|
seq:User
|
string
|
維護當前類型User的ID自增序列,用做對象唯一ID
|
|
ids:User
|
set
|
同一類型User所有對象ID的列表
|
|
urn:user:1
|
string
|
user對象
|
seq:User 維護的是類型User的ID序列 redisUsers.GetNextSequence()
public long GetNextSequence(int incrBy)
{
return IncrementValueBy(SequenceKey, incrBy);
}
public long IncrementValue(string key)
{
return client.Incr(key);
}
這里的SequenceKey就是 "seq:User",然后我們通過存一個對象到Redis看另外兩個key是什么作用:
public T Store(T entity)
{
var urnKey = entity.CreateUrn();
this.SetEntry(urnKey, entity);
return entity;
}
//entity.CreateUrn();的結果是"urn:user:1"
public void SetEntry(string key, T value)
{
if (key == null)
throw new ArgumentNullException("key");
client.Set(key, SerializeValue(value));
client.RegisterTypeId(value);
}
internal void RegisterTypeId<T>(T value)
{
var typeIdsSetKey = GetTypeIdsSetKey<T>();
var id = value.GetId().ToString();
if (this.Pipeline != null)
{
var registeredTypeIdsWithinPipeline = GetRegisteredTypeIdsWithinPipeline(typeIdsSetKey);
registeredTypeIdsWithinPipeline.Add(id);
}
else
{
this.AddItemToSet(typeIdsSetKey, id);
}
}
這里的typedIdsSetKey 就是"ids:User"
ids:User相當於一個索引,包含了所有同為類型User的ID;由於維護了這樣一個分組信息,所以很容易實現GetAll<User>()這樣的功能;
在redis-cli中查詢一下 get urn:user:1 返回值是
JSON格式:
"{\"Id\":1,\"Name\":\"Oren Eini\",\"BlogIds\":[1]}"
ServiceStack.Redis 自己實現了一套序列化功能,
Fastest JSON Serializer for .NET released 支持 POCO(Plain Old CLR Object)序列化.
實際應用中,由於我們使用的數據是來自關系型數據庫,本身包含關聯關系,所以並不需要這樣的對象組織方式;我們只需要把關系型數據中一對多的關系在Redis中表達出來即可;這里我擴展修改了RedisClient的實現,由於RedisClient本身已經通過
partial方式
分割成若干個文件,所以很容易把變動的代碼集中在同一個代碼文件中.具體業務對象存儲,主帖和回帖會有字段級修改,所以設計成為Hash結構,其它幾個子對象讀寫都是以對象為單位,設計成為POCO方式持久化;
使用管道Pipeline遇到的問題
使用管道可以將客戶端到Redis的往返次數減少,不過在使用ServiceStack.Redis的時候,遇到這樣一個問題,比如要把一個List<log>全部存儲,代碼不可以寫成下面這樣:
%%第一種寫法
logs.ForEach(n =>
{
pipeline.QueueCommand(r =>
{
((RedisClient)r).Store<OpLog>(n, n.GetObjectID(), n.GetUrnKey());
((RedisClient)r).Expire(n.GetUrnKey(), dataLifeTime);
});
});
而是要寫成這樣:
%%第二種寫法
logs.ForEach(n =>
{
pipeline.QueueCommand(r => ((RedisClient)r).Store<Log>(n, n.ID, n.GetUrnKey()));
pipeline.QueueCommand(r => ((RedisClient)r).Expire(n.GetUrnKey(), dataLifeTime));
});
什么原因呢?RedisQueueCompletableOperation的AddCurrentQueuedOperation方法會在 執行CurrentQueuedOperation = null;如果按照第一種寫法會丟失回調函數,這就造成有返回值在沒有及時提取,后續的操作獲取返回值時首先取到的是積壓的結果信息,就出現了異常,而第二種寫法就避免了這個問題.
protected virtual void AddCurrentQueuedOperation()
{
this.QueuedCommands.Add(CurrentQueuedOperation);
CurrentQueuedOperation = null;
}
Redis工具篇
Redis的客戶端redis-cli不是太好用,退格鍵和箭頭都不能正常使用,這個的確影響效率,還是需要找一個合適的工具,我比較喜歡這個:
RedisConsole
這個工具用來學習是很好用的,但是數據量一旦增大,左側列表就混亂了,而且一點擊就假死;所以建議只在學習階段使用;
在沒有window的環境,啟動一個Erlang的客戶端也是一個不錯的選擇.
Web端的管理工具我選用的是 Redis Admin UI
這個ServiceStack.Redis的配套項目,修改一下web.config就能用,地址在此:
http://www.servicestack.net/mythz_blog/?p=381
Redis圖書資料:
剛剛在NOSQLFan上看到一篇<Memcached真的過時了嗎？>一定要轉過來:
這兩年Redis火得可以，Redis也常常被當作Memcached的挑戰者被提到桌面上來。關於Redis與Memcached的比較更是比比皆是。然而，Redis真的在功能、性能以及內存使用效率上都超越了Memcached嗎？
下面內容來自Redis作者在stackoverflow上的一個回答，對應的問題是《Is memcached a dinosaur in comparison to Redis?》（相比Redis，Memcached真的過時了嗎？）
- You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.
- 沒有必要過多的關心性能，因為二者的性能都已經足夠高了。由於Redis只使用單核，而Memcached可以使用多核，所以在比較上，平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。說了這么多，結論是，無論你使用哪一個，每秒處理請求的次數都不會成為瓶頸。（比如瓶頸可能會在網卡）
- You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.
- 如果要說內存使用效率，使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis采用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。當然，這和你的應用場景和數據特性有關。
- You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.
- 如果你對數據持久化和數據同步有所要求，那么推薦你選擇Redis，因為這兩個特性Memcached都不具備。即使你只是希望在升級或者重啟系統后緩存數據不會丟失，選擇Redis也是明智的。
- You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don’t need just GEt/SET but more complex things Redis can help a lot (think at timeline caching).
- 當然，最后還得說到你的具體應用需求。Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網絡IO的次數和數據體積。在Redis中，這些復雜的操作通常和一般的GET/SET一樣高效。所以，如果你需要緩存能夠支持更復雜的結構和操作，那么Redis會是不錯的選擇。
注意:實踐版本 Redis 2.4.9
2013-3-22 16:30:30 更新
Rdbtools is a parser for Redis' dump.rdb files. The parser generates events similar to an xml sax parser, and is very efficient memory wise.
In addition, rdbtools provides utilities to :
- Generate a Memory Report of your data across all databases and keys
- Convert dump files to JSON
- Compare two dump files using standard diff tools