Posts

2019 FLAG 🚩 2018 明明知道自己要干什么，却时而缺乏执行能力，2019强化自我执行能力，学会规划，养成阅读习惯，自我记录与思考； 考研 这是一年后的又一次尝试，但这次提前准备，结果一定不会差。 数学是考研的一道大坎了，这势必要啃下来！ 英语语法还是有薄弱的，需要啃一本语法书（需要规划进执行力行动中），单词每周都会背， 但是需要一个检验环节（执行力行动加入单词默写/短文阅读批注行动） 从之前的考试来看，专业的内容多为项目工程的内容，算法大多为基础数据结构和基础排序，虽然不在话下， 但是考虑到工作需要，在准备环节需要适当加强技能巩固； 职业 what i want? 现在的公司肯定不是我想留下来的，其实已经落后了，虽然表面上说是形势原因， 但内心真实的内容是自己在2018年的执行力欠佳的主要原因，2019稳住自己，能战胜自己的人，就没有人能无法超越； 学会 GOLAN and RUST K8S 精通 算法 100题使用 java/golan 通刷（主要总结算法思想及相关算法适用案例） github 提交（执行力计划，编年史汇结内容感想） 参与一个开源项目开发 软件架构案例学习与思考（两周一次） 学会沟通 做一个有趣的人，干一些有趣的事情；

ubuntu18.xx 中修改 mysql 数据库默认字符编码 今天更换meriadb 为mysql 之后发现 springboot jpa存入数据库中的字符是乱码，看了下问题为mysql字符编码不是 utf-8了 ubuntu18 默认mysql配置文件地址 sudo vim /etc/mysql/conf.d/mysql.cnf 编辑文件内容 1 2 3 4 5 6 7 8 9 10 [mysql] default-character-set=utf8 [client] default-character-set=utf8 [mysqld] collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8 重启mysql sudo service mysql restart 注意 如果已经存在的库中乱码，手动重设字符编码/删除重建;

解锁正确的缓存姿势 1. 常见概念 在合理应用缓存前，需要了解缓存领域里相关的几个常用术语： 1）缓存命中：表示数据能够从缓存中获取，不需要回源； 2）Cache miss：表示没有命中缓存，如果缓存内存中还有内存空间的话，会将数据加入到缓存中； 3）存储成本：当没有命中缓存时，回源获取后会将数据放置到存储中，整个将数据放置到存储空间所需要的时间以及空间称之为存储成本； 4）缓存失效：当源数据发生变更后，意味着缓存中的数据失效； 5）缓存污染：将不经常访问的数据放置到缓存存储空间中，以至于高频访问的数据无法放置到缓存中； 6）替代策略：当数据放置到缓存空间时，由于空间不足时，就需要从缓存空间中去除已有的数据，选择去除哪些数据就是由替代策略决定的。常见的替代策略有如下这些： Least-Recently-Used（LRU） Least-Frequently-Used（LFU） SIZE First in First Out（FIFO） 由于存储空间有限，替代策略要解决的核心问题是尽量保留高频访问的缓存数据，降低缓存污染以提升缓存命中率和整体的缓存效率，难点在于，需要基于数据历史访问情况，以一种合适的对未来访问情况的预估才能找到更佳的策略。 2. 访问缓存场景 分析 使用缓存通常的操作是，请求先访问缓存数据，如果缓存中不存在的话，就会回源到数据库中然后将数据写入到缓存中；如果存在的话就直接返回数据。从整个过程来看，缓存层就处于数据访问的前置环节，分担数据库在高并发容易出现系统故障的风险，所以在使用过程中需要对缓存层很谨慎的进行分析。在访问缓存数据时，有常见的三大场景：缓存穿透、缓存击穿以及缓存雪崩。 2.1 缓存穿透 现象： 每次请求直接穿透缓存层，直接回源到数据库中，给数据库带来了巨大访问压力，甚至宕机。 原因： 访问数据会先访问缓存，如果数据不存在缓存中才会查询数据库，但是如果查询数据库也查询不出来数据，也是说当前访问数据永远不会写入缓存中。这样就导致了，访问一定不存在的数据，就相当于缓存层形同虚设，每次请求都会到db层，造成数据库负担过大。 解决方案： 方案一：采用bloom filter保存缓存过的key，在访问请求到来时可以过滤掉不存在的key，防止这些请求到db层； 方案二：如果db查询不到数据，保存空对象到缓存层，设置较短的失效时间； 方案三：针对业务场景对请求的参数进行有效性校验，防止非法请求击垮db。 2.2 缓存击穿 现象： 当某一key失效时，造成大量请求到db层，击垮存储层。 原因： 为了保证缓存数据的时效性，通常会设置一个失效时间，如果是热点key，高并发时会有海量请求直接越过缓存层到数据库，这样就会给数据库造成的负担增大，设置宕机。 解决方案 方案一：使用互斥锁，当缓存数据失效时，保证一个请求能够访问到数据库，并更新缓存，其他线程等待并重试； 方案二：缓存数据“永远不过期”，如果缓存数据不设置失效时间的话，就不会存在热点key过期造成了大量请求到数据库。但是，缓存数据就变成“静态数据”，因此当缓存数据快要过期时，采用异步线程的方式提前进行更新缓存数据。 2.3 缓存雪崩 现象： 多个key失效，造成大量请求到db层，导致db层负担过重甚至宕机。 原因： 缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到数据库，最终导致数据库瞬时压力过大而崩溃。 解决方案： 方案一：使用互斥锁的方式，保证只有单个线程进行请求能够达到db； 方案二：多每个key的失效时间在基础时间上再加上一个1~5分钟的随机值，这样就能保证大规模key集体失效的概率，并且需要尽量让多个key的失效时间能够均匀分布； 2.4 总结 缓存穿透、缓存击穿以及缓存雪崩这三个术语很容易弄混，也是读缓存中典型的三个场景问题，做一下简单的总结是很有必要的。缓存穿透强调是获取本不存在的缓存数据，请求必然会越过缓存层直接到达到存储层，很明显这是利用业务规则的漏洞对系统发起攻击，解决方案的核心原则是过滤这些非法业务请求，与是否是热点数据、缓存失效时间等因素没有关系。 缓存击穿强调的是热点key的失效，导致某一时刻大量请求会直接到db层，解决方案的核心原则是规避数据库的并发操作。缓存雪崩强调的多个key的集体失效，与key是否是热点数据并不是必然的因素，解决方案的核心原则则让key之间的失效时间分布更加均匀，避免集体失效的情况。 3 数据更新场景分析 引入缓存后数据会分别存放到缓存以及数据库两个地方，因此数据更新时，需要涉及到这两处地方得更新，并且更新时序的不同会有不同的结果。关于数据更新目前业界已经沉淀了Cache Aside Pattern，Read/Write through等多种方式。 3.1 Cache Aside Pattern 这是很通用的更新策略，主要流程如下： 图片来源： 酷 壳 - CoolShell 1 ...