❶ redis與timesten哪個好
內存資料庫從范型上可以分為關系型內存資料庫和鍵值型內存資料庫。
在實際應用中內存資料庫主要是配合oracle或mysql等大型關系資料庫使用，關注性能。
作用類似於緩存，並不注重數據完整性和數據一致性。
基於鍵值型的內存資料庫比關系型更加易於使用，性能和可擴展性更好，因此在應用上比關系型的內存資料庫使用更多。
比較FastDB、Memcached和Redis主流內存資料庫的功能特性。
FastDB的特點包括如下方面：
1、FastDB不支持client-server架構因而所有使用FastDB的應用程序必須運行在同一主機上；
2、fastdb假定整個資料庫存在於RAM中，並且依據這個假定優化了查詢演算法和介面。
3、fastdb沒有資料庫緩沖管理開銷，不需要在資料庫文件和緩沖池之間傳輸數據。
4、整個fastdb的搜索演算法和結構是建立在假定所有的數據都存在於內存中的，因此數據換出的效率不會很高。
5、Fastdb支持事務、在線備份以及系統崩潰後的自動恢復。
6、fastdb是一個面向應用的資料庫，資料庫表通過應用程序的類信息來構造。
FastDB不能支持Java API介面，這使得在本應用下不適合使用FastDB。
Memcached
Memcached是一種基於Key-Value開源緩存伺服器系統，主要用做資料庫的數據高速緩沖，並不能完全稱為資料庫。
memcached的API使用三十二位元的循環冗餘校驗（CRC-32）計算鍵值後，將資料分散在不同的機器上。當表格滿了以後，接下來新增的資料會以LRU機制替換掉。由於 memcached通常只是當作緩存系統使用，所以使用memcached的應用程式在寫回較慢的系統時（像是後端的資料庫）需要額外的程序更新memcached內的資料。
memcached具有多種語言的客戶端開發包，包括：Perl、PHP、JAVA、C、Python、Ruby、C#。
Redis
Redis是一個高性能的key-value資料庫。redis的出現，很大程度補償了memcached這類keyvalue存儲的不足，在部分場合可以對關系資料庫起到很好的補充作用。它提供了C++、Java、Python，Ruby，Erlang，PHP客戶端。
❷ redis做庫存需要持久化到資料庫嗎
redis做緩存數據的，持久化的數據要放資料庫
❸ C#怎麼使用redis實現秒殺功能
大概思路吧：
秒殺系統的架構設計
秒殺系統，是典型的短時大量突發訪問類問題。對這類問題，有三種優化性能的思路：
寫入內存而不是寫入硬碟
非同步處理而不是同步處理
分布式處理
用上這三招，不論秒殺時負載多大，都能輕松應對。更好的是，Redis能夠滿足上述三點。因此，用Redis就能輕松實現秒殺系統。
用我這個方案，無論是電商平台特價秒殺，12306火車票秒殺，都不是事:)
下面介紹一下為什麼上述三種性能優化思路能夠解決秒殺系統的性能問題：
寫入內存而不是寫入硬碟
傳統硬碟的讀寫性能是相當差的。SSD硬碟比傳統硬碟快100倍。而內存又比SSD硬碟快10倍以上。因此，寫入內存而不是寫入硬碟，就能使系統的能力提升上千倍。也就是說，原來你的秒殺系統可能需要1000台伺服器支撐，現在1台伺服器就可以扛住了。
你可能會有這樣的疑問：寫入內存而不是持久化，那麼如果此時計算機宕機了，那麼寫入的數據不就全部丟失了嗎？如果你就這么倒霉碰到伺服器宕機，那你就沒秒到了，有什麼大不了？
最後，後面真正處理秒殺訂單時，我們會把信息持久化到硬碟中。因此不會丟失關鍵數據。
Redis是一個緩存系統，數據寫入內存後就返回給客戶端了，能夠支持這個特性。非同步處理而不是同步處理
像秒殺這樣短時大並發的系統，在性能負載上有一個明顯的波峰和長期的波谷。為了應對相當短時間的大並發而准備大量伺服器來應對，在經濟上是相當不合算的。
因此，對付秒殺類需求，就應該化同步為非同步。用戶請求寫入內存後立刻返回。後台啟動多個線程從內存池中非同步讀取數據，進行處理。如用戶請求可能是1秒鍾內進入的，系統實際處理完成可能花30分鍾。那麼一台伺服器在非同步情況下其處理能力大於同步情況下1800多倍！
非同步處理，通常用MQ(消息隊列)來實現。Redis可以看作是一個高性能的MQ。因為它的數據讀寫都發生在內存中。分布式處理
好吧。也許你的客戶很多，秒殺系統即使用了上面兩招，還是捉襟見肘。沒關系，我們還有大招：分布式處理。如果一台伺服器撐不住秒殺系統，那麼就多用幾台伺服器。10台不行，就上100台。分布式處理，就是把海量用戶的請求分散到多個伺服器上。一般使用hash實現均勻分布。
這類系統在大數據雲計算時代的今天已經有很多了。無非是用Paxos演算法和Hash Ring實現的。
Redis Cluster正是這樣一個分布式的產品。
使用Redis實現描述系統
Redis和Redis Cluster（分布式版本），是一個分布式緩存系統。其支持多種數據結構，也支持MQ。Redis在性能上做了大量優化。因此使用Redis或者Redis Cluster就可以輕松實現一個強大的秒殺系統。
基本上，你用Redis的這些命令就可以了。
RPUSH key value
插入秒殺請求
當插入的秒殺請求數達到上限時，停止所有後續插入。
後台啟動多個工作線程，使用
LPOP key
讀取秒殺成功者的用戶id，進行後續處理。
或者使用LRANGE key start end命令讀取秒殺成功者的用戶id，進行後續處理。
每完成一條秒殺記錄的處理，就執行INCR key_num。一旦所有庫存處理完畢，就結束該商品的本次秒殺，關閉工作線程，也不再接收秒殺請求。
要是還撐不住，該怎麼辦
也許你會說，我們的客戶很多。即使部署了Redis Cluster，仍然撐不住。那該怎麼辦呢？
記得某個偉人曾經說過：辦法總比困難多！
下面，我們具體分析下，還有哪些情況會壓垮我們架構在Redis（Cluster）上的秒殺系統。
腳本攻擊
如現在有很多搶火車票的軟體。它們會自動發起http請求。一個客戶端一秒會發起很多次請求。如果有很多用戶使用了這樣的軟體，就可能會直接把我們的交換機給壓垮了。
這個問題其實屬於網路問題的范疇，和我們的秒殺系統不在一個層面上。因此不應該由我們來解決。很多交換機都有防止一個源IP發起過多請求的功能。開源軟體也有不少能實現這點。如linux上的TC可以控制。流行的Web伺服器Nginx（它也可以看做是一個七層軟交換機）也可以通過配置做到這一點。一個IP，一秒鍾我就允許你訪問我2次，其他軟體包直接給你丟了，你還能壓垮我嗎？
交換機撐不住了
可能你們的客戶並發訪問量實在太大了，交換機都撐不住了。
這也有辦法。我們可以用多個交換機為我們的秒殺系統服務。
原理就是DNS可以對一個域名返回多個IP，並且對不同的源IP，同一個域名返回不同的IP。如網通用戶訪問，就返回一個網通機房的IP；電信用戶訪問，就返回一個電信機房的IP。也就是用CDN了！
我們可以部署多台交換機為不同的用戶服務。 用戶通過這些交換機訪問後面數據中心的Redis Cluster進行秒殺作業。
總結
有了Redis Cluster的幫助，做個支持海量用戶的秒殺系統其實So Easy！
這里介紹的方案雖然是針對秒殺系統的，但其背後的原理對其他高並發系統一樣有效。
最後，我們再重溫一下高性能系統的優化原則：
寫入內存而不是寫入硬碟
非同步處理而不是同步處理
分布式處理
❹ redis適合什麼場景
1、緩存。 緩存現在幾乎是所有中大型網站都在用的必殺技，合理的利用緩存不僅能夠提升網站訪問速度，還能大大降低資料庫的壓力。Redis提供了鍵過期功能，也提供了靈活的鍵淘汰策略，所以，現在Redis用在緩存的場合非常多。（推薦：《 Redis視頻教程 》）
2、排行榜。 很多網站都有排行榜應用的，如京東的月度銷量榜單、商品按時間的上新排行榜等。Redis提供的有序集合數據類構能實現各種復雜的排行榜應用。
3、計數器。 什麼是計數器，如電商網站商品的瀏覽量、視頻網站視頻的播放數等。為了保證數據實時效，每次瀏覽都得給+1，並發量高時如果每次都請求資料庫操作無疑是種挑戰和壓力。Redis提供的incr命令來實現計數器功能，內存操作，性能非常好，非常適用於這些計數場景。
4、分布式會話。 集群模式下，在應用不多的情況下一般使用容器自帶的session復制功能就能滿足，當應用增多相對復雜的系統中，一般都會搭建以Redis等內存資料庫為中心的session服務，session不再由容器管理，而是由session服務及內存資料庫管理。
5、分布式鎖。 在很多互聯網公司中都使用了分布式技術，分布式技術帶來的技術挑戰是對同一個資源的並發訪問，如全局ID、減庫存、秒殺等場景，並發量不大的場景可以使用資料庫的悲觀鎖、樂觀鎖來實現，但在並發量高的場合中，利用資料庫鎖來控制資源的並發訪問是不太理想的，大大影響了資料庫的性能。可以利用Redis的setnx功能來編寫分布式的鎖，如果設置返回1說明獲取鎖成功，否則獲取鎖失敗，實際應用中要考慮的細節要更多。
❺ 什麼時候用Redis
默認情況下，redis
服務會提供
16
個資料庫，phphub
使用
0
號資料庫來做緩存，1
號資料庫來做會話存儲
-
laravel
下配置
redis
讓緩存、session
各自使用不同的
redis
資料庫_phphub
隊列的話使用
beanstalkd
最常用的就是緩存、隊列，當然還有很多其它的，如歸並計算、去重等。
我根據自己使用redis的場景及個人最佳實踐，整理了一篇文章，redis應用場景與最佳實踐
比如網站搶購時，可以使用redis做隊列，可以使用redis來代替session功能，還有可以拿redis中的無序集合做socket的客戶端id存儲。
❻ redis怎樣解決高並發
1.Redis存取數據是基於內存的，而內存的讀寫速度非常快，這是前提。
2.Redis是單線程的，省去了很多切換線程的時間消耗。(PS：Redis單線程指的是網路請求模塊使用了一個線程（所以不需考慮並發安全性），即一個線程處理所有網路請求，其他模塊仍用了多線程。PPS：目前新版的Redis分支也在深入的探索多線程的方式，理論效率要高於目前市面上的穩定版本。)
3.Redis採用網路IO多路復用技術（非阻塞IO）來保證在多連接的時候，系統的高吞吐量。而非阻塞IO，其內部實現採用了epoll並結合了本身實現的簡單的事件框架，epoll中的讀、寫、關閉、連接都轉化成了事件，然後利用epoll的多路復用特性極大的節省了在處理IO上的時間。（PS：多路復用指的是多個socket連接復用一個線程。而epoll是目前最好的多路復用技術，所以使用epoll實現多路I/O復用技術可以讓單個線程高效的處理多個連接請求，從而達到盡量減少網路IO的時間消耗）
❼ redis 開啟事務以後 為什麼要判斷 小於0 高手舉個例子 講詳細 急用！！！
很簡單，請求進來直接減庫存(始終認為庫存是足夠的)，然後判斷如果這次真的減掉了庫存，庫存的總量會不會小於0（超賣），如果小於0，這次的操作與預期有出入（庫存超賣），所以，後續的寫庫等其它操作應該被中止，然後進來的時候減掉的庫存應該還原（因為一進入的時候就假設庫存足夠，但庫存已經為0了），因為後續的寫庫操作沒有執行，保證了寫庫數據始終正常，不會出現超賣，但redis中的緩存需要進行一次修正