Redis

在程序中可以使用缓存的技术来节省对数据库的开销。Spring Boot对缓存提供了很好的支持，我们几乎不用做过多的配置即可使用各种缓存实现。这里主要介绍平日里个人接触较多的Ehcache和Redis缓存实现。 准备工作 可根据 Spring-Boot中使用Mybatis.html 搭建一个Spring Boot项目，然后yml中配置日志输出级别以观察SQL的执行情况： 1 2 3 4 5 logging: level: com: springboot: mapper: debug 其中 com.spring.mapper 为MyBatis的Mapper接口路径。 然后编写如下测试方法： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 @RunWith (SpringJUnit4ClassRunner.class) @SpringBootTest (classes = Application.class) public class ApplicationTest { @Autowired private StudentService studentService; @Test public void test () throws Exception { Student student1 = this .studentService

Redis构建简单的主从复制 原理： 当设置好slave服务器后，slave会建立和master的连接，然后发送sync命令。无论是第一次同步建立的连接还是连接断开后的重新连 接，master都会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存起来。后台进程完成写文件 后，master就发送文件给slave，slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到slave上。 配置前提，关闭防火墙或允许redis端口通行 Centos7 IP:10.0.0.128（master） IP:10.0.0.129（slave） 主服务器配置： 下载安装包，解压并编译； [root@master ~]# cd /usr/local/src/ [root@master src]# wget [root@master src]# tar -zxvf redis-stable.tar.gz [root@master src]# mv redis-stable /usr/local/redis [root@master src]# cd /usr/local/redis/ [root@master redis]# make && make install copy配置文件redis.conf到/etc/目录下 [root@master redis]

今天我们继续来讨论协议，今天基本就把一对一聊天的协议定制完毕了，上一篇我们讲述了登录的过程，那么登录完毕就是聊天了，首先我们还是以A和B为例子，A发送消息给B，那么这条消息的的协议如下 发送消息协议： {"id":"xxxx","#":"msg","text":"内容","to":"接收用户ID","type":0,"msgid":"消息ID" ｝ id:客户端生成的ID #:不说了，我们之前说过，是对应服务器端的Handler text:消息内容 to:表示发送给谁 type：表示消息类型 msgid：表示消息的ID 肯定有很多人之后看到之后会有一个问题，我们到底需不需要from 也就是说发送者是谁，其实在这里加上也行，但是其实是不需要的，因为如果既然这个人可以发送消息，那么我们可以在这个人对应的回话里边去存储这个人的信息，所以说只要发送消息，服务器就知道这条消息来自谁，故不需要在这里加from，然后服务器端要响应给该用户是否发送成功，返回的协议，我们在上一篇 auth那里讲述了，用同一个就好了，那么现在服务器如果发现B在线该去通知B来收消息了，那么我们看一下服务器通知B的协议 服务器通知B的协议： {"id":"xxxx","#":"psh"} id：服务器生成的id #：我们这里用了一个psh表示，通知该用户你有新的消息，要获取了，那么B解析到

2020年05月06号 计划明天回到无锡，今日下班后突然感受到一种巨困，脖子僵硬加头部不清醒，十分难受外加饥饿，一种眩晕感袭来。 今日工作比较清晰，一件一件的慢慢处理，在下午下班时，处理完全，可以好好考虑明天的行程了。 好好考虑在无锡精进的日程了。明天，需要好好思考反省。 今日工作之收获: 1> 完成azure function对event hub的实验操作 2> 回想不起来咯 今日关键字: 又，又一次感受到超级困的感受，十分难受。神经，脖子，头痛，眼睛困，肚子胀。 2020年05月07日 今日休假返回无锡，明天开始农历过年后第一天在办公室上班的感受。今天确实心里活动很丰富，记录在工作日杂中，这里就只是提醒自己的心理活动很丰富。 今天有运动，有控制饮食，也有思考和困顿。 今日关键字: 精进之计划，闭关修炼开始时。 2020年05月08号 今日开始无锡办公室上班，非常不习惯大屏显示器家目前的工作状态，个人处于进入状态的情况，人不好，很不好。对问题处理不集中。 今日之事: 1/ 接手一个新case，处理cloud service中的一个错误消息，查询到与激活许可证有关 2/ 与lina一起讨论apim案例，到底apim发送请求到后端server的ip地址是多少呢？验证下来就是apim的vip，而不是请求中所说的x forward for。地址，这也是自己很疑惑的地方，那x

步骤 1：配置选型 针对个人用户和企业用户的不同需求，阿里云分别为您 推荐了不同的架构 。 适合个人用户的配置 入门型： 1 vCPU 1 GB 1 MB，适用于访问量较小的个人网站初级阶段。 基础型： 1 vCPU 2 GB 1 MB，适用于流量适中的网站、简单开发环境、代码存储库等。 通用型： 2 vCPU 4 GB 1 MB，能满足 90% 云计算用户，适用于企业运营活动、并行计算应用、普通数据处理。 进阶型： 4 vCPU 8 GB 1 MB，用于对计算性能要求较高的业务，如企业运营活动、批量处理、分布式分析、应用 APP 等。 适合企业用户的配置 内存型： 1:8 (vCPU:内存) 分配，I/O 优化，适用 Cache/Redis、搜索类、内存数据库等需使用大量内存的应用。 计算型： 最大规格为 40 核 vCPU，224 GB 内存，可以满足 CPU 密集型超稳定计算需求。 通用型： Intel Xeon E5 CPU，DDR4 内存，最大 256 Mbps 吞吐量，最大 20000 IOPS 随机读写，已成为 70% 企业用户的选择。 安全型： 购买 ECS 时直接绑定安全增强服务，DDoS 防护阈值 10 GB 起，支持手动解除黑洞，支持 5 * 8 小时安全事件响应。 这些推荐配置只是作为您开始使用云服务器 ECS 的参考。阿里云提供了灵活、可编辑的配置修改方式

目前在网上看到的大部分文章都是通过keys 进行模糊匹配并删除的 下面介绍3种删除方法,建议使用linux去操作,可以结合 xargs(点击查看介绍) 命令进行操作 参数说明: [ip]: ip地址, 参数名 -> -h [port]: 端口号, 参数名 -> -p [password]: 密码, 参数名 -> -a, 没有密码则不输入 -a [password] [index]: 缓存所在的库, 参数名 -> -n keys命令 它会扫整个库,导致Redis阻塞,影响正常使用, 不建议使用 redis-cli -h [ip] -p [port] -a [password] -n [index] keys "User:*" | xargs redis-cli -h [ip] -p [port] -a [password] -n [index] del 这是目前网上常用的方法,通过keys 命令返回匹配到的key,然后再使用 xargs整合所有的并删除 但是这个方法有个致命的问题,就是它是通过keys去扫描模糊匹配, keys命令会导致Redis阻塞问题,并且keys命令在生产环境是禁用的 scan命令 它是通过游标的方式扫描 (推荐) redis-cli -h [ip] -p [port] -a [password] -n [index] --scan --pattern

缓存 缓存的作用： 高并发、高性能 高性能：查询速度快 高并发：缓存是走内存的，内存天然就支撑高并发 常见缓存问题： 缓存与数据库双写不一致 缓存雪崩、缓存穿透、缓存击穿 缓存并发竞争 如何保证缓存和数据库一致性： 使用串行化，即：将读请求和写请求放到一个内存队列中。 串行化可以保证缓存与数据库一直，但是会导致系统吞吐量大幅度降低。非严格要求，不要串行化。 经典缓存+DB读写模式 》读：先读缓存，没有读取DB,读出来放入缓存。 》更新：先更新DB,再 删除 缓存。 缓存雪崩 请求量大时，缓存此时也跌机了，导致大量请求直接请求DB,带着DB也跌机了。 缓存雪崩的事前事中事后的解决方案： 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 缓存穿透 缓存中查询不到，大量的请求直接查询DB. 解决方案： 每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN 。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。 缓存击穿 某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况

https://blog.csdn.net/weixin_42456466/article/details/87270959 来源： oschina 链接： https://my.oschina.net/u/4470945/blog/4329007

今天早上，新来的同事小王突然问我：“周哥，什么是幂等性啊？”。然后我就跟他解释了一番，幂等性就是说无论你执行几次请求，其结果是一样的。说到了幂等就不得不说重复提交了，你连续点击提交按钮，理论上来说这是同一条数据，数据库应该只能存入一条，而实际上存放了多条，这就违反了幂等性。因此我们就需要做一些处理，来保证连续点击提交按钮后，数据库只能存入一条数据。 防止重复提交的方式很多，这里我就说一下我认为比较好用的一种。 自定义注解+Aop实现 我们通过获取用户ip及访问的接口来判断他是否重复提交，假如这个ip在一段时间内容多次访问这个接口，我们则认为是重复提交，我们将重复提交的请求直接处理即可，不让访问目标接口。 自定义注解 @Target({ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface NoRepeatSubmit { /** * 默认1s钟以内算重复提交 * @return */ long timeout() default 1; } Aop处理逻辑 我们将ip+接口地址作为key，随机生成UUID作为value，存入redis。每次请求进来，根据key查询redis，如果存在则说明是重复提交，抛出异常，如果不存在，则是正常提交，将key存入redis。

配置服务模块，有点像配置中心，不过功能暂时还没那么强大。 后期完善后会更新源码地址。 目录 项目功能简介 项目核心配置代码 环境配置 MVC静态资源隐射配置 项目功能简介 系统环境监测： MVC资源访问映射： Swagger接口文档配置： Redis 操作RedisTemplate配置： 项目核心配置代码 环境配置 通过判定系统做对应的初始化和依赖检查工作。 package com.patrol.config; import com.patrol.beans.OSInfo; import com.patrol.config.condition.LinuxCondition; import com.patrol.config.condition.WindowsCondition; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Conditional; import org.springframework.context.annotation