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，數據可持久化
1.緩存和數據庫雙寫一致性問題
2.緩存雪崩問題
3.緩存擊穿問題
4.緩存的並發競爭問題
下面是redis用作緩存，不是redis數據庫，數據庫需要落地，持久化數據。
redis過期策略以及內存淘汰機制
redis只能存5G數據，寫入了10G數據，需要刪掉5G，如何刪？
加入數據設置了過期時間但是時間到了，內存占用率還是高是為何？
定期刪除+惰性刪除，redis默認100ms檢查，是否有過期的key，有就刪除，但不是檢查所有的key，而是隨機出去，如果全部key檢查可能卡死。
還可以配置淘汰機制
1.redis和數據庫雙一致性問題，一致性問題是分布式常見問題，一致性可以分為最終一致性和強一致性，數據庫和緩存雙寫，就必然會存在不一致的問題。如果對數據庫有強一致性要求，就不能放緩存。使用緩存只能保證最終一致性，所有的方案只能降低不一致發生的概率，無法完全避免。
需要采用正確的更新策略，先更新數據庫，再刪緩存。其次因為可能存在刪除緩存失敗的問題，提供一個補償措施即可，例如利用消息隊列。
2.如何應對緩存穿透和緩存雪崩問題
一般中小型傳統軟件企業難以碰到這個問題，如果有大並發的項目，流量幾百萬做偶遇，需要審核考慮。
緩存穿透，即黑客故意去請求緩存中不存在的數據，導致所有的請求都堆到數據庫上面，從而數據庫連接異常。
解決方案，三個方案
緩存雪崩，即統一時間大面積的失效，這個時候又來了一波請求，結果請求都堆到數據庫上，導致數據庫來接異常。三個解決方案，給緩存加上失效時間。
4.並發競爭問題，多個子系統同時取set一個key。分布式鎖，有鎖的才能set。
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適合做數據庫嗎？
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的替換品。
不是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造成的阻塞並未考慮進去