開發者提供的介面非常簡單明了,從Ehcache的搭建到運用運行僅僅需要的是你寶貴的幾分鐘。其實很多開發者都不知道自己用在用Ehcache,Ehcache被廣泛的運用於其他的開源項目
memcache支持多個cpu同時工作,在memcache安裝文件下有個叫threads.txt中特別說明,By default, memcached is compiled as a single-threaded application.默認是單線程編譯安裝,如果你需要多線程則需要修改./configure --enable-threads,為了支持多核系統,前提是你的系統必須具有多線程工作模式。開啟多線程工作的線程數默認是4,如果線程數超過cpu數容易發生操作死鎖的概率。結合自己業務模式選擇才能做到物盡其用。
2.先安裝libevent:
# tar zxvf libevent-1.2.tar.gz
# cd libevent-1.2
# ./configure -prefix=/usr
# make (如果遇到提示gcc 沒有安裝則先安裝gcc)
# make install
3.測試libevent是否安裝成功:
# ls -al /usr/lib | grep libevent
lrwxrwxrwx 1 root root 21 11?? 12 17:38 libevent-1.2.so.1 -> libevent-1.2.so.1.0.3
-rwxr-xr-x 1 root root 263546 11?? 12 17:38 libevent-1.2.so.1.0.3
-rw-r-r- 1 root root 454156 11?? 12 17:38 libevent.a
-rwxr-xr-x 1 root root 811 11?? 12 17:38 libevent.la
lrwxrwxrwx 1 root root 21 11?? 12 17:38 libevent.so -> libevent-1.2.so.1.0.3
還不錯,都安裝上了。
4.安裝memcached,同時需要安裝中指定libevent的安裝位置:
# cd /tmp
# tar zxvf memcached-1.2.0.tar.gz
# cd memcached-1.2.0
# ./configure -with-libevent=/usr
# make
# make install
如果中間出現報錯,請仔細檢查錯誤信息,按照錯誤信息來配置或者增加相應的庫或者路徑。
安裝完成後會把memcached放到 /usr/local/bin/memcached ,
5.測試是否成功安裝memcached:
# ls -al /usr/local/bin/mem*
-rwxr-xr-x 1 root root 137986 11?? 12 17:39 /usr/local/bin/memcached
-rwxr-xr-x 1 root root 140179 11?? 12 17:39 /usr/local/bin/memcached-debug
啟動memcache服務
啟動Memcached服務:
1.啟動Memcache的伺服器端:
# /usr/local/bin/memcached -d -m 8096 -u root -l 192.168.77.105 -p 12000 -c 256 -P /tmp/memcached.pid
-d選項是啟動一個守護進程,
-m是分配給Memcache使用的內存數量,單位是MB,我這裡是8096MB,
-u是運行Memcache的用戶,我這裡是root,
-l是監聽的伺服器IP地址,如果有多個地址的話,我這裡指定了伺服器的IP地址192.168.77.105,
-p是設置Memcache監聽的埠,我這裡設置了12000,最好是1024以上的埠,
-c選項是最大運行的並發連接數,默認是1024,我這裡設置了256,按照你伺服器的負載量來設定,
-P是設置保存Memcache的pid文件,我這裡是保存在 /tmp/memcached.pid,
2.如果要結束Memcache進程,執行:
# cat /tmp/memcached.pid 或者 ps -aux | grep memcache (找到對應的進程id號)
# kill 進程id號
也可以啟動多個守護進程,不過埠不能重複。
memcache 的連接
telnet ip port
注意連接之前需要再memcache服務端把memcache的防火牆規則加上
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT
重新載入防火牆規則
service iptables restart
OK ,現在應該就可以連上memcache了
在客戶端輸入stats 查看memcache的狀態信息
pid memcache伺服器的進程ID
uptime 伺服器已經運行的秒數
time 伺服器當前的unix時間戳
version memcache版本
pointer_size 當前操作系統 的指針大小(32位系統一般是32bit)
rusage_user 進程的累計用戶時間
rusage_system 進程的累計系統時間
curr_items 伺服器當前存儲的items數量
total_items 從伺服器啟動以後存儲的items總數量
bytes 當前伺服器存儲items佔用的位元組數
curr_connections 當前打開著的連接數
total_connections 從伺服器啟動以後曾經打開過的連接數
connection_structures 伺服器分配的連接構造數
cmd_get get命令 (獲取)總請求次數
cmd_set set命令 (保存)總請求次數
get_hits 總命中次數
get_misses 總未命中次數
evictions 為獲取空閑內存而刪除的items數(分配給memcache的空間用滿後需要刪除舊的items來得到空間分配給新的items)
bytes_read 讀取位元組數(請求位元組數)
bytes_written 總發送位元組數(結果位元組數)
limit_maxbytes 分配給memcache的內存大小(位元組)
threads 當前線程數
redis
Redis 是在memcache之後編寫的,大家經常把這兩者做比較,如果說它是個key-value store 的話但是它具有豐富的數據類型,我想暫時把它叫做緩存數據流中心,就像現在物流中心那樣,order、package、store、classification、distribute、end。現在還很流行的LAMP PHP架構 不知道和 redis+MySQL 或者 redis + MongoDB 的性能比較(聽群里的人說mongodb分片不穩定)。
先說說reidis的特性
1. 支持持久化
redis的本地持久化支持兩種方式:RDB和AOF。RDB 在redis.conf配置文件里配置持久化觸發器,AOF指的是redis沒增加一條記錄都會保存到持久化文件中(保存的是這條記錄的生成命令),如果不是用redis做DB用的話還會不要開AOF ,數據太龐大了,重啟恢復的時候是一個巨大的工程!
2.豐富的數據類型
redis 支持 String 、Lists、sets、sorted sets、hashes 多種數據類型,新浪微博會使用redis做nosql主要也是它具有這些類型,時間排序、職能排序、我的微博、發給我的這些功能List 和 sorted set的強大操作功能息息相關
3.高性能
這點跟memcache很想像,內存操作的級別是毫秒級的比硬碟操作秒級操作自然高效不少,較少了磁頭尋道、數據讀取、頁面交換這些高開銷的操作!這也是NOSQL冒出來的原因吧,應該是高性能
是基於RDBMS的衍生產品,雖然RDBMS也具有緩存結構,但是始終在app層面不是我們想要的那麼操控的。
4.replication
redis提供主從複製方案,跟mysql一樣增量複製而且複製的實現都很相似,這個複製跟AOF有點類似複製的是新增記錄命令,主庫新增記錄將新增腳本發送給從庫,從庫根據腳本生成記錄,這個過程非常快,就看網路了,一般主從都是在同一個區域網,所以可以說redis的主從近似及時同步,同事它還支持一主多從,動態添加從庫,從庫數量沒有限制。 主從庫搭建,我覺得還是採用網狀模式,如果使用鏈式(master-slave-slave-slave-slave·····)如果第一個slave出現宕機重啟,首先從master 接收 數據恢復腳本,這個是阻塞的,如果主庫數據幾TB的情況恢復過程得花上一段時間,在這個過程中其他的slave就無法和主庫同步了。
5.更新快
這點好像從我接觸到redis到目前為止 已經發了大版本就4個,小版本沒算過。redis作者是個非常積極的人,無論是郵件提問還是論壇發帖,他都能及時耐心的為你解答,維護度很高。有人維護的話,讓我們用的也省心和放心。目前作者對redis 的主導開發方向是redis的集群方向。
redis的安裝
redis的安裝其實還是挺簡單的,總的來說就三步:下載tar包,解壓tar包,安裝。
不過最近我在2.6.7後用centos 5.5 32bit 時碰到一個安裝問題,下面我就用圖片分享下安裝過程碰到的問題,在redis 文件夾內執行make時有個如下的錯 undefined reference to __sync_add_and_fetch_4
上網找了了好多最後在 https:// github.com/antirez/redi s/issues/736 找到解決方案,write CFLAGS= -march=i686 on src/Makefile head!
記得要把剛安裝失敗的文件刪除,重新解壓新的安裝文件,修改Makefile文件,再make安裝。就不會發現原來那個錯誤了
最後,把memcache和redis放在一起不得不會讓人想到兩者的比較,誰快誰好用啊,群裡面已經為這個事打架很久了,我就把我看到的在這裡跟大家分享下。
在別人發了一個memcache性能比redis好很多後,redis 作者 antirez 發表了一篇博文,主要是說到如何給redis 和 memcache 做壓力測試,文中講到有個人說許多開源軟體都應該丟進廁所,因為他們的壓力測試腳本太2了,作者對這個說明了一番。redis vs memcache is definitely an apple to apple comparison。 呵呵,很明確吧,兩者的比較是不是有點雞蛋挑骨頭的效果,作者在相同的運行環境做了三次測試取多好的值,得到的結果如下圖:
需要申明的是此次測試在單核心處理的過程的數據,memcache是支持多核心多線程操作的(默認沒開)所以在默認情況下上圖具有參考意義,若然則memcache快於redis。那為什麼redis不支持多線程多核心處理呢?作者也發表了一下自己的看法,首先是多線程不變於bug的修復,其實是不易軟體的擴展,還有數據一致性問題因為redis所有的操作都是原子操作,作者用到一個詞nightmare 噩夢,呵呵! 當然不支持多線程操作,肯定也有他的弊端的比如性能想必必然差,作者從2.2版本後專註redis cluster的方向開發來緩解其性能上的弊端,說白了就是縱向不行,橫向提高。應用場景:
ehcache直接在jvm虛擬機中緩存,速度快,效率高;但是緩存共享麻煩,集群分散式應用不方便。
redis是通過socket訪問到緩存服務,效率比ecache低,比資料庫要快很多,處理集群和分散式緩存方便,有成熟的方案。如果是單個應用或者對緩存訪問要求很高的應用,用ehcache。如果是大型系統,存在緩存共享、分散式部署、緩存內容很大的,建議用redis。補充下:ehcache也有緩存共享方案,不過是通過RMI或者Jgroup多播方式進行廣播緩存通知更新,緩存共享複雜,維護不方便;簡單的共享可以,但是涉及到緩存恢復,大數據緩存,則不合適。喜歡這篇文章的可以給筆者點個贊同,關注一下,每天都會分享Java相關文章!還有不定時的福利贈送,包括整理的學習資料,面試題,源碼等~~
推薦閱讀: