TerminalLight
本科生
获得徽章 1
- #青训营笔记创作活动#
2月12日 打卡day30
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
跨域问题的本质是浏览器为了保证用户的一种安全拦截机制，想要解决跨域问题，只需要告诉浏览器“我是自己人，不要拦我”就行。它的常见实现方式有 5 种：通过注解实现局部跨域、通过配置文件实现全局跨域、通过 CorsFilter 对象实现全局跨域、通过 Response 对象实现局部跨域，通过 ResponseBodyAdvice 实现全局跨域。展开评论1 - #青训营笔记创作活动#
2月11日 打卡day29
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
· 对于一个 UserTask 而言，任务处理人有四种：
流程发起人，由流程的启动人/发起人来处理这个流程。
单个用户，直接指定某一个具体的用户来处理这个流程，注意这里只能指定一个用户，并且这个用户将来在处理任务的时候，不需要认领，直接就可以处理。
候选用户：可以同时指定多个用户来处理这个 UserTask，将来用户在处理的时候，需要先认领（Claim）任务，然后才能处理。
候选组：可以同时指定多个用户组来处理这个 UserTask，这个处理的时候，也需要先认领，再处理。
· 基本概念：
流程定义（ProcessDefinition）：绘制的流程图、流程的 XML 文件，就是流程定义。
流程（ProcessInstance）：一个启动了流程实例就是一个流程，流程可以是已经执行完毕的，也可以是正在执行中的。流程的定义相当于是一个类，而流程则相当于是一个对象。
任务（Task）：一个 ProcessInstance 中，需要具体处理的节点就是一个任务。展开评论1 - #青训营笔记创作活动#
2月10日 打卡day28
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
工具模块本身并不会被启动，没有启动类、配置文件，这种情况下该如何获得redis？
找引入的模块要 RedisTemplate。因为这些Bean都是被spring管控的，包括RedisTemplate、RequestLimitAspect ，它们将来都是在spring容器内的，所以可以直接在代码里找spring进行注入就可以。将来引入的模块中如果有RedisTemplate可用，自然就可以拿到。展开评论1 - #青训营笔记创作活动#
2月9日 打卡day27
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
如何选择client模式和proxy模式，可以从以下几个方面来简单做下比较。
1、性能
性能方面client模式表现的稍好一些，它是直接连接MySQL执行命令；
proxy代理服务则将整个执行链路延长了，应用->代理服务->MySQL，可能导致性能有一些损耗，但两者差距并不是非常大。
2、复杂度
client模式在开发使用通常引入一个jar可以；
proxy代理模式则需要搭建单独的服务，有一定的维护成本，既然是服务那么就要考虑高可用，毕竟应用的所有SQL都要通过它转发至MySQL。
3、升级
client模式分库分表一般是依赖基础架构团队的Jar包，一旦有版本升级或者Bug修改，所有应用到的项目都要跟着升级。小规模的团队服务少升级问题不大，如果是大公司服务规模大，且涉及到跨多部门，那么升级一次成本就比较高；
proxy模式在升级方面优势很明显，发布新功能或者修复Bug，只要重新部署代理服务集群即可，业务方是无感知的，但要保证发布过程中服务的可用性。
4、治理、监控
client模式由于是内嵌在应用内，应用集群部署不太方便统一处理；proxy模式在对SQL限流、读写权限控制、监控、告警等服务治理方面更优雅一些。展开评论1 - #青训营笔记创作活动#
2月8日 打卡day26
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
· 自旋锁：一种是没有获取到锁的线程就一直循环等待判断该资源是否已经释放锁，它不用将线程阻塞起来(NON-BLOCKING)；
· 互斥锁：把自己阻塞起来，等待重新调度请求。
自旋锁的思想其实也就是一个while（true）一直重试罢了。
还有使用过openfegin的朋友会知道，它在发送请求时，也包含有一个重试机制，很多高可用的场景
· 消息队列自身是很好的支持高可用的。
· 首先消息队列在高并发的场景下，可以毋庸置疑的说是一个非常重要的组件啦，所以· 引入消息队列以及维护消息队列，其实都不能算是额外的负担。
· 其次消息队列具有持久化，即使项目重启也不会丢失。
· 最后消息队列自身可以实现可靠性
· 保证消息成功发送，发送到交换机；
· 保证消息成功从交换机发送至队列；
· 消费者端接收到消息，采用手动ACK确认机制，成功消费后才会删除消息，消费失败则重新投递展开评论1 - #青训营笔记创作活动#
2月7日 打卡day25
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
· 在高并发类的系统中进行数据更新的时候，缓存与数据库的数据一致性问题，是一个永远无法绕过的话题。对于基于旁路型缓存的大部分业务而言，数据更新操作，一般可以组合出几种不同的处理策略：
先更新缓存，再更新数据库
先更新数据库， 再更新缓存
先删除缓存，再更新数据库
先更新数据库，再删除缓存
· 由于大部分数据库都支持事务，而几乎所有的缓存操作都不具有事务性。所以在一些写操作并发不是特别高且一致性要求不是特别强烈的情况下，可以简单的借助数据库的事务进行控制。比如先更新数据库再更新缓存，如果缓存更新失败则回滚数据库事务。
· 然而在一些并发请求特别高的时候，基于事务控制来保证数据一致性往往会对性能造成影响，且事务隔离级别设置的越高影响越大，所以也可以采用一些其它辅助策略，来替代事务的控制，如重试机制、或异步补偿机制、或多者结合方式等。展开评论1 - #青训营笔记创作活动#
2月6日 打卡day24
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
（1）瞬时高并发问题
瞬时高并发的场景，传统的系统很难应对，我们需要设计一套全新的系统。可以从以下几个方面入手：
页面静态化
CDN加速
缓存
mq异步处理
限流
分布式锁
（2）延迟消费问题
在15分钟内未完成支付，订单被自动取消的功能，要如何实现呢？
job，因为它比较简单，但job需要每隔一段时间处理一次，实时性不太好时，可以使用延迟队列。我们都知道rocketmq，自带了延迟队列的功能。展开评论1 - #青训营笔记创作活动#
2月5日 打卡day23
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
1.大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定情况下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
2.HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
3.TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。
4.TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。展开评论1 - #青训营笔记创作活动#
2月4日 打卡day22
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
（1）缓存穿透：
缓存穿透是指缓存和数据库上都没有的数据，导致所有请求都落到数据库上，造成数据库短时间内承受大量的请求而导致宕机。
解决方法：
· 方法1：使用布隆过滤器，将查询的参数都存储到一个 bitmap 中，在查询缓存前，如果 bitmap 存在则进行底层缓存的数据查询，如果不存在则进行拦截，不再进行缓存的数据查询
·方法2：使用缓存空对象，如果数据库查询的为空，则依然把这个数据缓存并设置过期时间，当多次访问的时候可以直接返回结果，避免造成多次访问数据库，但要保证当数据库有数据时及时更新缓存。
（2）缓存击穿
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），就会导致所有请求都落到数据库上，造成数据库段时间内承受大量的请求而宕机。
解决方法：
· 方法1：设置热点数据永不过期。
· 方法2：可以使用互斥锁更新，保证同一进程中针对同一个数据不会并发请求到 DB，减小DB的压力。
· 方法3：使用随机退避方式，失效时随机 sleep 一个很短的时间，再次查询，如果失败再执行更新。展开评论1 - #青训营笔记创作活动#
2月3日 打卡day21
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
由于MySQL是作为存储层部署在业务系统的最后端，所有的业务数据最终都要入库落盘，但随着一个项目在线上运行的时间越来越久，数据库中的数据量自然会越来越多，而数据体积出现增长后，当需要从表查询一些数据时，效率会越发低下。
在正常情况下，表的查询性能和数据量是成反比的，也就是数据越多，查询越慢，这是由于MySQL默认的查询方式导致的。展开评论1