redis简单了解

Redis 是单进程程序

redis与memcache对比
1、redis能够用不同的两种方式将数据写入磁盘（时间点转储即快照；只追加文件AOF，将所有修改了数据库的命令都写入一个只追加文件里面，用户可以根据数据的重要程度，将只
追加写入设置为从不同步、每秒同步一次或者每写入一个命令就同步一次）
2、redis除了能够存储普通的字符串键外还能存储其他4种的数据结构，而memcache只能存储普通的字符串键

一、事务

在事务处理过程中，可能会遇到两种命令错误:
1、命令可能无法排队，因此在调用EXEC之前可能存在错误
2、在调用EXEC之后，命令可能会失败，

对应错误的处理方式：
在2.6.5版本之前在Redis 2.6.5之前，其行为是只使用命令的子集来执行事务，以防客户端调用EXEC，而不考虑之前的错误。新的行为使得将事务与管道进行混合变得更加简单，这样整个事务就可以同时发送，同时读取所有的响应。
在2.6.5版本之后服务器将记住在积累命令期间发生了错误，并将拒绝执行在执行过程中返回错误的事务，并自动丢弃事务。

执行EXEC后发生的错误不会以特殊的方式处理:所有其他命令都将执行，即使在事务中某些命令失败。

从上面两点可以看出redis不支持回滚：
在事务期间Redis命令可能会失败，但是Redis将执行事务的其余部分，而不是回滚
1、Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
2、因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。 有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。
总之这块被认为是开发人员自己的错误造成的

WATCH指令用于为Redis事务提供检查和设置(check-and-set, CAS)行为。

redis-chech-aof工具

二、发布/订阅（https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern）
客户端订阅一个或多个频道而不必发出命令，尽管他能订阅和取消订阅其他频道。订阅和取消订阅的响应被封装在发送的消息中，以便客户端只需要读一个连续的消息流，其中第一个元素表示消息类型。

推送消息的格式
消息格式包括三个元素 。 
第一个元素是消息类型:
subscribe: 表示我们成功订阅到响应的第二个元素提供的频道。第三个参数代表我们现在订阅的频道的数量。
unsubscribe:表示我们成功取消订阅到响应的第二个元素提供的频道。第三个参数代表我们目前订阅的频道的数量。当最后一个参数是0的时候，我们不再订阅到任何频道。当我们在Pub/Sub以外状态，客户端可以发出任何redis命令。
message: 这是另外一个客户端发出的发布命令的结果。第二个元素是来源频道的名称，第三个参数是实际消息的内容。

数据库与作用域：
发布/订阅与key所在空间没有关系，它不会受任何级别的干扰，包括不同数据库编码。 发布在db 10,订阅可以在db 1。 如果你需要区分某些频道，可以通过在频道名称前面加上所在环境的名称（例如：测试环境，演示环境，线上环境等）

模式匹配订阅
Redis 的Pub/Sub实现支持模式匹配。客户端可以订阅全风格的模式以便接收所有来自能匹配到给定模式的频道的消息。

三、redis的sentinel（哨兵）
redis的哨兵为redis提供了高可用