qq_50675319的博客

无论是哪种数据类型， key都是string类型，string类型的底层编码包含int、embstr和raw三种。如果key中全是数字，那么就会直接以int类型去存储，而int占用的空间也是最小的，当然出于业务需求，我们不可能将key设计为一个全数字的，而如果不是纯数字，底层存储的就是SDS内容，如果小于44字节，就会使用embstr类型，embstr在内存中是一段连续的存储空间，内存占用相对raw来说较小，而当字节数大于44字节时，会转为raw模式存储，在raw模式下，内存空间不是连续的，而是采用一个指针

在分片集群中，数据key并不是与某个节点绑定，而是与插槽绑定。数据key与插槽是多对一的关系，redis会根据key的有效部分计算插槽值，然后将key放入对应插槽，key的有效部分分两种情况：当key中包含"{}“时，且”{}“中至少包含1个字符，”{}"中的部分是有效部分key中不包含"{}"，整个key都是有效部分举个例子，假如key是num，那么插槽值就会根据num来计算，如果key是{itheima}num，那么插槽值就会根据itheima来计算。计算方式是利用CRC16算法得到一个hash

哨兵的作用如下：监控：Sentinel会不断检查master和slave是否按预期工作自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障的master恢复之后也以新的master为主通知：Sentinel可以充当Redis客户端的服务发现来源，Redis客户端无需再直接连接Redis节点，而是连接Sentinel，由Sentinel提供主从节点的地址信息，当集群发生故障转移，即有slave被提升为master后，Sentinel 会将服务状态的变更通知

主从第一次建立连接后，slave会向master发送数据同步的请求。master在接收到slave的请求后，首先会判断slave是不是第一次请求，如果是第一次请求，master则会将其版本信息返回给slave，而slave在接收到master的版本信息后，会将其保存下来。master在向slave同步数据时，会执行bgsave命令，异步开辟独立进程来生成RDB文件。RDB文件一旦生成，master就会将RDB文件发送给slave。slave在接收到master发送过来的RDB文件后，首先会清空本地数据，

Redis是运行在内存中的，这样虽然性能高，但是数据的安全却很难得到保证，一旦Redis服务出现宕机，那么存储在内存中的数据就会全部丢失，为了防止出现这样的问题，需要使用到Redis的持久化技术，即将内存中的数据保存在磁盘中，防止数据丢失Redis有两种常见的持久化方案：分别为RDB持久化和AOF持久化。

用户签到的功能我们完全可以通过mysql来完成，比如说建立以下表：但是用户一次签到，就会在数据库中保存一条记录，假如有1000万用户，平均每人每年签到次数为10次，则这张表一年的数据量为 1亿条，假设每签到一次需要使用（8 + 8 + 1 + 1 + 3 + 1）共22 字节的磁盘空间，那么这一年下来，光是签到信息就会占用2G多的磁盘空间，这显然是不合适的。

前端发起查询时，会发送商户类型、页码、当前用户的经度和维度四个参数，我们只需要以该经纬度为圆心，分页查询出一定范围内指定类型的商户信息然后即可，geo会自动帮我们完成排序这里geo的key中需要携带上商户的分类信息，因为前端发起的查询指定商户的类型，而geo中又没有办法保存相应的类型信息，因此最好将商户的类型设计到geo的key中，按类型分别来保存geo为了尽量节省内存空间，geo的member我们只需要保存商户id即可。

GEO、BitMap、HyperLogLog是redis中三种特殊的数据结构，一般用于实现特殊的业务场景，其底层都是基于redis中的基础数据类型存储的。

当用户关注了博主之后，如果博主再发布动态，我们就应该将动态信息推送给用户，这个需求叫做关注推送，也叫做Feed流，直译为投喂，目的是为用户持续的提供"沉浸式"的体验，通过无限下拉刷新获取新的信息对于传统模式的内容解锁，是需要用户主动地去通过搜索引擎或者是其他的方式去解锁自己想要看的内容。而对于新型的Feed流的的效果则刚好相反，不需要用户再主动去寻找自己想看的内容，而是系统分析用户到底想要看什么，然后直接把内容推送给用户，从而使用户能够更加节约时间。

探店笔记类似点评网站的评价，往往是图文结合。具体发布流程如下：UploadController（已完成）这里需要注意一点，将SystemConstants类中的IMAGE_UPLOAD_DIR改成自己nginx中imgs目录的绝对路径BlogController（已完成）

通过加锁可以解决在单机情况下的一人一单安全问题，但是在集群模式下就不行了。1.我们将服务启动两份，端口分别为8081和8082：2.然后修改nginx的conf目录下的nginx.conf文件，配置反向代理和负载均衡：3.重新加载nginx，命令为4.经过测试，最终发现在集群模式下，有多少个服务，用户最多就能下多少单，也就是说在集群模式下，我们之前使用的悲观锁失效了为什么会出现上述现象呢？

为了解决上述XREAD命令的问题，我们可以使用消费者组（Consumer Group），所谓的消费者组就是将多个消费者划分到一个组中，监听同一个队列。它具备下列特点消息分流：队列中的消息会分流给组内的不同消费者，而不是重复消费，从而加快消息处理的速度。处于一个组内的多个消费者实际上是竞争关系，凡是进入到这个组的消息，组内的消费者就会竞争该消息的处理权。这种方式可以大大提高消息的处理速度，避免消息堆积。如果想要一条消息被多个消费者处理，可以添加多个消费者组。消息标识、消息确认

上述任务的执行时间我们可以看到，是internalLockLeaseTime / 3，那么这个internalLockLeaseTime又是多少呢？其实这里的internalLockLeaseTime和我们之前提到的看门狗过期时间是同一个时间，也就是30秒，也就是说这里任务的执行时间就是10秒之后，而每当我们执行一次任务之后，任务内部又会再次调用renewExpiration()，也就是说这段任务每隔10秒就会执行一次，刷新当前线程持有锁的有效期，模拟一个锁永不过期的效果，这个任务也就被称为"看门狗"

每个店铺都可以发布优惠券：当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在一些问题：id的规律性太明显如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。受单表数据量的限制。

在原来的业务逻辑中，如果用户查询缓存未命中，会去直接查询数据库，在这种情况下，如果用户查询的是热点数据且缓存重建比较复杂，就容易出现缓存击穿问题，这里我们可以假设商铺查询就是热点数据，需要针对缓存击穿问题设计相应的解决方案相较于原来从缓存中查询不到数据后直接查询数据库而言，现在的方案是进行查询之后，如果从缓存未命中，则进行互斥锁的获取，获取互斥锁后，判断是否获得到了锁，如果没有获得锁，则休眠，过一段时间再对上述业务逻辑进行重试，获取到锁的线程可以需要去查询数据库并将数

缓存数据存储于代码中，而代码运行在内存中，内存的读写性能远高于磁盘，对于那些频繁查询而且对查询速度要求较高的数据，如果我们使用缓存，不仅可以大大降低用户访问并发量带来的服务器读写压力，而且可以给用户较好的体验实际开发过程中，企业的数据量，少则几十万，多则几千万，这么大数据量，如果没有缓存来作为"避震器"，系统是几乎撑不住的，所以企业会大量运用到缓存技术；但是使用缓存也有可能会出现各种各样的问题，例如缓存雪崩、缓存击穿、缓存穿透等等问题

当注册完成后，用户去登录会去校验用户提交的手机号和验证码，是否一致，如果一致，则根据手机号查询用户信息，不存在则新建，最后将用户数据保存到redis，并且生成token作为redis的key，当我们校验用户是否登录时，会去携带着token进行访问，从redis中取出token对应的value，判断是否存在这个数据，如果没有则拦截，如果存在则将其保存到threadLocal中，并且放行。

Jedis和Lettuce：这两个主要是提供了Redis命令对应的API，方便我们操作Redis，而SpringDataRedis又对这两种做了抽象和封装，因此我们一般都是直接学习SpringDataRedis,SpringDataRedis中提供了RedisTemplate工具类，其中封装了各种对Redis的操作。并且将针对不同数据类型的操作API封装到了不同的数据类型中，以便区别：

Redis是典型的key-value数据库，key一般是字符串，而value包含很多不同的数据类型，以下是常见的八种数据类型：上图中的前五种是最常见的数据类型，因而称之为redis的基本类型，而后三种数据类型是建立在前五种数据类型之上的，这些数据类型一般用于解决特定场景的业务需求，使用频率比前五种要低，因此也称为特殊类型除了以上八种数据类型以外，redis还包括很多种其他的数据类型，用来实现各种各样特殊的功能需求。

大多数企业都是基于Linux服务器来部署项目，而且Redis官方也没有提供Windows版本的安装包。因此我们会基于Linux系统来安装Redis.此处选择的Linux版本为CentOS 7

NoSql可以翻译做Not Only Sql（不仅仅是SQL），或者是No Sql（非Sql的）数据库。是相对于传统关系型数据库而言，有很大差异的一种特殊的数据库，因此也称之为非关系型数据库。常见的NoSQL数据库有Redis、MongoDB、Elasticsearch等等。传统关系型数据库是结构化数据，每一张表都有严格的约束信息，例如字段名、字段数据类型、字段约束等等，插入的数据必须遵守这些约束：而非关系型数据库则对数据库格式没有严格约束，往往形式松散，自由。