Redis 筆記系列（四）——redis零散知識雜記

如何測試你的redis服務的性能

這裏要用到redis的一個命令程序redis-benchmark

首先開啓redis-server服務。配置文件是什麼鬼？不知道看我上一篇博客文章。

[root@localhost bin]# redis-server /myconfigs/redis.conf 
[root@localhost bin]# 
[root@localhost bin]# ps -ef | grep redis
root       3892      1  0 07:39 ?        00:00:00 redis-server 127.0.0.1:6379
root       3905   3650  0 07:39 pts/0    00:00:00 grep --color=auto redis
[root@localhost bin]# 
[root@localhost bin]# redis-benchmark

 

而後就開始漫長的性能測試：

那麼性能測試都測試寫什麼呢？

redis的五大數據結構，我在後面的博客裏再介紹。每一個數據結構的都對應了許多命令操做，這些命令操做的性能如何，就是redis-benchmark在redis所在服務器機器上的性能測試結果。

例如，這裏，咱們看兩個命令，就是最近處的鍵值操做的get和set。咱們能夠看到在個人VM上，每2.28秒內能夠跑100,000次set請求，而跑100,000次get請求只須要1.65秒。

能夠看到，redis的性能是很是驚人的，也難過它在高負載、高併發的應用場景中一直扮演着舉足輕重的角色。若是你開發一個網站，全部的數據請求所有由mysql直接響應，那你的mysql多半要被高負載場景的大量請求活活壓死。有了redis，這些大量的數據請求就會被redis擋在緩存這一級，分擔至關的工做。

你不要說1.65秒才十萬次，你別忘了，我測試的環境是個人筆記本電腦上開的VM，虛擬內存也只有1G，在真實的服務器上，redis的響應請求的能力更加驚人。

 

Redis零散知識點羅列

redis是單進程

redis使用單進程模型來處理客戶端請求。

對讀寫等事件的響應是經過linux系統的epoll函數的包裝來作到的。簡單說，就是爲了快速讀寫，redis實現對讀寫事件的響應藉助了linux系統底層的epoll函數來實現。Epoll是linux內核爲處理大批量而作了改進的epoll，是linux下多路複用IO接口select/poll的加強版。它顯著提升程序在大量併發鏈接中只有少許活躍狀況下的系統CPU利用率。

 

Redis默認有16個數據庫

redis默認存在了16個數據庫，它們能夠用dbid進行標識，從0至15。這個數據庫的數量能夠在配置文件中修改設置。咱們打開配置文件：

[admin@localhost bin]$ vi /myconfigs/redis.conf

好，咱們默認進入redis-cli時進入的是0號庫。若是要切換庫，能夠用select 【dbid】命令來進行。

好比，咱們如今在0號庫，發現有k1這個鍵值對存在，切換到1號庫時，k1件就沒有值了：

[admin@localhost bin]$ redis-cli -p 6379
127.0.0.1:6379> 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get k1
"happyBKs"
127.0.0.1:6379> 
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> get k1
(nil)
127.0.0.1:6379[1]> 
127.0.0.1:6379[1]> 
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> get k1
"happyBKs"
127.0.0.1:6379>

注意：切到哪一個庫，命令行上會有[dbid]來標記，如[1]。0號庫缺省。

 

如何查看redis某個數據庫中鍵的個數呢？如何查看包含哪些鍵呢？

127.0.0.1:6379> DBSIZE
(integer) 4
127.0.0.1:6379> keys *
1) "k1"
2) "mylist"
3) "counter:__rand_int__"
4) "key:__rand_int__"
127.0.0.1:6379> 
127.0.0.1:6379>

能夠看到，除了咱們在上一篇博客中自行設置了一個k1鍵，還有三個redis默認自帶的鍵。

咱們在設置幾個鍵：

127.0.0.1:6379> set k2 22222
OK
127.0.0.1:6379> set k3 33333
OK
127.0.0.1:6379> 
127.0.0.1:6379> keys *
1) "key:__rand_int__"
2) "counter:__rand_int__"
3) "k2"
4) "mylist"
5) "k3"
6) "k1"
127.0.0.1:6379> keys k*
1) "key:__rand_int__"
2) "k2"
3) "k3"
4) "k1"
127.0.0.1:6379> 
127.0.0.1:6379> set k10 101010101
OK
127.0.0.1:6379> keys k?
1) "k2"
2) "k3"
3) "k1"
127.0.0.1:6379> keys k*
1) "key:__rand_int__"
2) "k2"
3) "k10"
4) "k3"
5) "k1"
127.0.0.1:6379>

 

如何清空鍵值對呢？

分爲兩種，flushdb清空當前所在數據庫的全部key；flushall清空全部數據庫的全部key。

下面的例子能夠看到，咱們嘗試在1號庫建了一個鍵，而後回到0號庫flushdb清空key，再回到1號庫發現db1_key1鍵還在。

27.0.0.1:6379> 
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> set db1_key1 sdfsadfasd
OK
127.0.0.1:6379[1]> keys *
1) "db1_key1"
127.0.0.1:6379[1]> 
127.0.0.1:6379[1]> 
127.0.0.1:6379[1]> 
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> keys *
1) "key:__rand_int__"
2) "counter:__rand_int__"
3) "k2"
4) "k10"
5) "mylist"
6) "k3"
7) "k1"
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> 
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> keys *
1) "db1_key1"
127.0.0.1:6379[1]> 
127.0.0.1:6379[1]>

flushall會將全部庫都gameover。因此必定要慎用。

127.0.0.1:6379[1]> 
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> keys *
(empty list or set)
127.0.0.1:6379[1]> 
127.0.0.1:6379[1]>

 

統一密碼管理：

在使用redis的時候，並無讓咱們輸入用戶名密碼，16個庫都一樣的密碼，要麼均可以，要麼都連不上。

安全加固應該在系統層面進行加固，redis將能訪問redis的用戶都默認做爲授信用戶。固然，redis也能夠設置用戶密碼登陸的方式，可是這與偏重於高併發和緩存應用場景十分不相符。

 

其餘

redis索引都是從0開始。

redis默認端口6379。