qq_38196449的博客

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。说白了Redis是基于内存的，快是快，但一关机数据就没了，这样肯定不行啊，所以就要把数据都存在磁盘上，这个操作就叫持久化。为什么要持久化？防止数据的意外丢失，确保数据安全性。哪有服务器一宕机数据就没的，这谁还用Redis？是redis的默认持久化机制。RDB相当于照快照，保存的是一种状态。几十G数据 —>几kb快照。快照是默认的持久化方式，这种方式就是将内存中数据以快照的方式写入到二进制。

并不是很慢的查询才是慢查询，而是：在Redis执行时耗时超过某个阈值的命令，称为慢查询。慢查询的危害：由于Redis是单线程的，所以当客户端发出指令后，他们都会进入到redis底层的queue来执行，如果此时有一些慢查询的数据，就会导致大量请求阻塞，从而引起报错，所以我们需要解决慢查询问题。慢查询的阈值可以通过配置指定：slowlog-log-slower-than：慢查询阈值，单位是微秒。

请求要经过Tomcat处理，Tomcat的性能成为整个系统的瓶颈。Redis缓存失效时，会对数据库产生冲击。多级缓存就是充分利用请求处理的每个环节，分别添加缓存，减轻Tomcat压力，提升服务性能：浏览器访问静态资源时，优先读取浏览器本地缓存访问非静态资源（ajax查询数据）时，访问服务端请求到达Nginx后，优先读取Nginx本地缓存如果Nginx本地缓存未命中，则去直接查询Redis（不经过Tomcat）如果Redis查询未命中，则查询Tomcat。

指定对哪个database记录binary log events，这里记录heima这个库。接下来添加一个仅用于数据同步的账户，出于安全考虑，这里仅提供对heima这个库的操作权限。Canal是基于MySQL的主从同步功能，因此必须先开启MySQL的主从功能才可以。：设置binary log文件的存放地址和文件名，叫做mysql-bin。：数据库地址和端口，如果不知道mysql容器地址，可以通过。打开mysql容器挂载的日志文件，我的在。：这是canal的默认监听端口。重启mysql容器即可。

nginx的默认配置文件注释太多，影响后续我们的编辑，这里将nginx.conf中的注释部分删除，保留有效部分。看到里面的nginx目录了吗，OpenResty就是在Nginx基础上集成了一些Lua模块。默认情况下，OpenResty安装的目录是：/usr/local/openresty。opm是OpenResty的一个管理工具，可以帮助我们安装一个第三方的Lua模块。NGINX_HOME：后面是OpenResty安装目录下的nginx的目录。仓库，这样就可以便于未来安装或更新我们的软件包（通过。

后期做数据同步需要用到MySQL的主从功能，所以需要大家在虚拟机中，利用Docker来运行一个MySQL容器。我们需要准备一个反向代理的nginx服务器，如上图红框所示，将静态的商品页面放到nginx目录中。之所以将库存分离出来，是因为库存是更新比较频繁的信息，写操作较多。而其他信息修改的频率非常低。现在，页面是假数据展示的。而这个请求地址同样是80端口，所以被当前的nginx反向代理了。tb_item_stock：商品库存表，包含商品的库存信息。商品查询是购物页面，与商品管理的页面是分离的。

那么有一种情况，假如子进程RDB写的过程比较慢，在子进程写的过程中，主进程不断的有新的请求过来，不断的修改共同数据，所有的数据都被修改了一遍，那么这种情况下意味着所有的数据都要拷贝一份，意味着对内存的占用翻倍了，这种情况理论上是有可能发生的，虽然是极端情况。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。那么既然是异步的，子进程在写RDB的过程中，主进程这时接收用户的请求来修改内存中的数据，主进程在写，子进程在读，那么会出现一些脏数据，为了避免此类情况发生。

GEO就是Geolocation的简写形式，代表地理坐标。Redis在3.2版本中加入了对GEO的支持，允许存储地理坐标信息，帮助我们根据经纬度来检索数据。常见的命令有：GEOADD：添加一个地理空间信息，包含：经度（longitude）、纬度（latitude）、值（member）GEODIST：计算指定的两个点之间的距离并返回GEOHASH：将指定member的坐标转为hash字符串形式并返回GEOPOS：返回指定member的坐标。

发布探店笔记探店笔记类似点评网站的评价，往往是图文结合。对应的表有两个：tb_blog：探店笔记表，包含笔记中的标题、文字、图片等，tb_blog_comments：其他用户对探店笔记的评价。注意：在操作时，需要修改SystemConstants.IMAGE_UPLOAD_DIR 自己图片所在的地址，在实际开发中图片一般会放在nginx上或者是云存储上。

答案是课程中的好，因为如果你采用我刚说的方式，如果访问的人很多，那么线程池中的线程可能一下子就被消耗完了，而且你使用上述方案，最大的特点在于，你觉得时效性会非常重要，但是你想想是吗？我们将耗时比较短的逻辑判断放入到redis中，比如是否库存足够，比如是否一人一单，这样的操作，只要这种逻辑可以完成，就意味着我们是一定可以下单完成的，我们只需要进行快速的逻辑判断，根本就不用等下单逻辑走完，我们直接给用户返回成功， 再在后台开一个线程，后台线程慢慢的去执行queue里边的消息，这样程序不就超级快了吗？

重入问题：重入问题是指获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。

缓存(Cache)，就是数据交换的缓冲区例1:Static final ConcurrentHashMap map = new ConcurrentHashMap();本地用于高并发例2:static final Cache USER_CACHE = CacheBuilder.newBuilder().build();用于redis等缓存例3:Static final Map map = new HashMap();本地缓存由于其被Static。

在这个方案中，他确实可以使用对应路径的拦截，同时刷新登录token令牌的存活时间，但是现在这个拦截器他只是拦截需要被拦截的路径，假设当前用户访问了一些不需要拦截的路径，那么这个拦截器就不会生效，所以此时令牌刷新的动作实际上就不会执行，所以这个方案他是存在问题的。也就是说，当用户操作拦截器配置的一些路径功能时，确实会保证刷新token，不会给你退出，但是你却避免不了用户操作的是拦截器没有配置的路径功能，比如首页、商户的详情页，这些页都是不用登录就能看的，这时用户也在操作，但你却给他退出了。

Redis Java客户端