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造成的阻塞并未考虑进去