redis 和postgresql區別以及其優缺點 一剎那者為一念，二十念為一瞬，二十瞬為一彈指，二十彈指為一羅預，二十羅預為一須臾，一日一夜有三十須臾。 那麼，經過周密的計算，一瞬間為0.36 秒,一剎那有 0.018 秒.一彈指長達 7.2 秒。 redis和postgresql區別： pg是一個關係資料庫，二redis是鍵值儲存。   redis為單執行緒，單執行緒一個執行緒定時寫入資料到磁碟。可以設定寫入資料量，比如多個客戶端一次寫入了10000條資料那我就1秒鐘寫一次，一次寫入量為1000條，我就10秒寫一次。 redis優點： 1.速度快，資料存於記憶體中，也可落地。 2.支援豐富資料型別。string，list，set，sorted set，hash 3.支援十五，操作都是原子性 4.可用於快取，訊息，按key設定過期時間，過期後自動刪除 redis缺點： redis適用場景： pg適用場景： redis相比 memcache有哪些優勢，1，型別豐富，2.速度快，3，資料可持久化   https://blog.csdn.net/hjm4702192/article/details/80518856 1.快取和資料庫雙寫一致性問題 2.快取雪崩問題 3.快取擊穿問題 4.快取的併發競爭問題   下面是redis用作快取，不是redis資料庫，資料庫需要落地，持久化資料。 redis過期策略以及記憶體淘汰機制 redis只能存5G資料，寫入了10G資料，需要刪掉5G，如何刪？ 加入資料設定了過期時間但是時間到了，記憶體佔用率還是高是為何？ 定期刪除+惰性刪除，redis預設100ms檢查，是否有過期的key，有就刪除，但不是檢查所有的key，而是隨機出去，如果全部key檢查可能卡死。 還可以配置淘汰機制 1.redis和資料庫雙一致性問題，一致性問題是分散式常見問題，一致性可以分為最終一致性和強一致性，資料庫和快取雙寫，就必然會存在不一致的問題。如果對資料庫有強一致性要求，就不能放快取。使用快取只能保證最終一致性，所有的方案只能降低不一致發生的概率，無法完全避免。 需要採用正確的更新策略，先更新資料庫，再刪快取。其次因為可能存在刪除快取失敗的問題，提供一個補償措施即可，例如利用訊息佇列。 2.如何應對快取穿透和快取雪崩問題 一般中小型傳統軟體企業難以碰到這個問題，如果有大併發的專案，流量幾百萬做偶遇，需要稽核考慮。 快取穿透，即黑客故意去請求快取中不存在的資料，導致所有的請求都堆到資料庫上面，從而資料庫連線異常。 解決方案，三個方案 快取雪崩，即統一時間大面積的失效，這個時候又來了一波請求，結果請求都堆到資料庫上，導致資料庫來接異常。三個解決方案，給快取加上失效時間。 4.併發競爭問題，多個子系統同時取set一個key。分散式鎖，有鎖的才能set。   redis持久化：

http://doc.redisfans.com/topic/persistence.html 1.rdb持久化方式能夠在指定的時間間隔將資料進行快照儲存，備份快，備份檔案小，恢復快，適合用於備份。如果想盡量避免伺服器故障丟失資料，rdb不適合。 2.aof持久化記錄伺服器執行的所偶遇寫操作命令，並在伺服器啟動時，通過執行這些命令來還原資料集。備份檔案大，備份滿，可以設定fsync策略，每秒鐘同步一次資料，丟失資料只是一秒的資料。 一般來說， 如果想達到足以媲美 PostgreSQL 的資料安全性， 你應該同時使用兩種持久化功能。 原文：https://blog.csdn.net/chenfengdejuanlian/article/details/54728852 1、 同時開啟兩種方式優先使用AOF方式。 2、 一般來說，如果想達到足以媲美 PostgreSQL 的資料安全性， 你應該同時使用兩種持久化功能。 3、 如果你非常關心你的資料， 但仍然可以承受數分鐘以內的資料丟失， 那麼你可以只使用 RDB 持久化。 4、 有很多使用者都只使用 AOF 持久化， 但我們並不推薦這種方式： 因為定時生成 RDB 快照（snapshot）非常便於進行資料庫備份， 並且 RDB 恢復資料集的速度也要比 AOF 恢復的速度要快， 除此之外， 使用 RDB 還可以避免之前提到的 AOF 程式的 bug 。     redis適合做資料庫嗎？ http://www.voidcn.com/article/p-kxvfenpt-brx.html redis能不能拿來當資料庫，取決於你想要儲存什麼資料： 如果你打算儲存一些臨時資料，資料規模不大，不需要太複雜的查詢，但是對效能的要求比較高，那可以拿redis當資料庫使用。 redis 能不能做資料庫，要看你具體的需求了： 1. 像上面提到的，redis的持久化有問題，如果使用aof模式，並且fsync always，則效能比mysql 還低，如果你喜歡redis 方便的資料結構而對效能要求不高，或者效能要求很高，但允許一定程度的丟失資料，則可以用redis做為資料庫。

2. redis 是記憶體資料庫， 記憶體寫滿後，資料不會儲存到硬碟上（VM 不穩定，diskstore未啟用），如果你記憶體足夠大，則可以用redis作為資料庫。   redis主要是效率高，鍵值對儲存。雖然pg也支援鍵值儲存，但是redis資料是在記憶體，速度很快。所以使用的場景也主要是對查詢效率有高要求的專案。 適合於redis。1.存一些臨時資料，資料規模不大，不需要太複雜的查詢，但是對效能要求高。 但是缺點也很明顯，1.redis資料持久化問題，雖然可以設定aof的模式，但是還是會有可能丟失一部分資料,不能達到資料庫的永久儲存。2.不支援過於複雜的查詢，3.維護不方便.4.資料遷移問題，如果從redis遷移到像pg這樣的庫就存在問題。5.資料型別少(和資料庫相比)，   持久化效率不高，從redis遷移到資料庫，而涉及到資料遷移會存在問題。 只支援簡單的查詢，不能支援複雜的查詢。 redis並不是為了作為資料庫使用的，它更多地是一個高速存取器，一般用作快取和類似場景 由於本身產品的一些限制，我們限制是將redis作為memcached的替換品。 https://my.oschina.net/aslanjia/blog/691716 不是sql server、mySQL等關係型資料庫，主要原因是：       . redis目前還只能作為小資料量儲存（全部資料能夠載入在記憶體中） ，海量資料儲存方面並不是redis所擅長的領域    redis資料太多超過記憶體大小： 1.分散式快取 2.增大記憶體 3.刪除過期資料,定期把資料寫入到硬碟中.     最後，把我使用過程中的一些 經驗與教訓，做個小結：  1. 要進行Master-slave配置，出現服務故障時可以支援切換。  2. 在master側禁用資料持久化，只需在slave上配置資料持久化。  3. 實體記憶體+虛擬記憶體不足，這個時候dump一直死著，時間久了機器掛掉。這個情況就是災難！  4. 當Redis實體記憶體使用超過記憶體總容量的3/5時就會開始比較危險了，就開始做swap,記憶體碎片大  5. 當達到最大記憶體時，會清空帶有過期時間的key，即使key未到過期時間.  6. redis與DB同步寫的問題，先寫DB，後寫redis，因為寫記憶體基本上沒有問題  

• RDB和AOF可能會對Redis造成的阻塞並未考慮進去