如何设计一个精壮的服务

最近辞职以后，在准备面试和简历期间，回顾了之前在工作期间出现的服务问题。有一些事故中，是因为某个或某几个服务被高峰期的流量打趴，可能是数据库问题，亦有可能是内存等等各种问题。其深层次的背后，是服务本身不够健壮，服务的某个或某几个节点被打趴以后，导致重试风暴，继而又导致雪崩的出现。如果这些服务是主流程上的服务的话，那就有可能导致全系统的雪崩。

Docker Colima

在mac 上，要运行docker ，需要通过docker desktop 创建docker运行的环境，但是这玩意太重了，风扇总是飞起。于是找到了一个代替docker desktop的轻量级工具，缺点是没有可视化界面。

介绍

Colima 是一个以最小化设置来在MacOS上运行容器运行时和 Kubernetes 的工具。

MAT(Java堆分析工具)使用方式

最近在整理笔记，发现之前在分析JAVA内存问题时写的Mat工具文档还是蛮清晰的，现重新整理一下，分享出来。

MAT是个啥

MAT 全称 Eclipse Memory Analysis Tools 是一个分析 Java堆数据的专业工具，可以计算出内存中对象的实例数量、占用空间大小、引用关系等，看看是谁阻止了垃圾收集器的回收工作，从而定位内存泄漏的原因。

什么时候会用到

• OutOfMemoryError的时候，触发full gc，但空间却回收不了，引发内存泄露
• java服务器系统异常，比如load飙高，io异常，或者线程死锁等，都可能通过分析堆中的内存对象来定位原因

散列

散列（Hash）也称为哈希，就是把任意长度的输入，通过散列算法，变换成固定长度的输出，这个输出值就是散列值。

散列算法

在实际使用中，不同的输入可能会散列成相同的输出，这时也就产生了冲突。 这时候，我们就希望有一些算法可以保证散列表的足够散列程度，降低冲突几率。

散列算法的宗旨就是：构造冲突较低的散列地址，保证散列表中数据的离散度。

除法散列法

散列长度 m, 对于一个小于 m 的数 p 取模，所得结果为散列地址。对 p 的选择很重要，一般取素数或 m

f(k) = k % p （p<=m）

ConcurrentHashMap类图

根据类图看出来，ConcurrentHashMap实现了 Map 接口，继承了 AbstractMap 抽象类，所以大多数的方法也都和我们平时用到的HashMap是相同的，HashMap 有的方法，ConcurrentHashMap 几乎都有，所以当我们需要从 HashMap 切换到 ConcurrentHashMap 时，无需关心两者之间的兼容问题。

从微服务看稳定性建设

本文主要依据微服务，从"防范稳定性风险"和"降低故障影响"两个方面简单介绍了稳定性建面临的常见问题。

1.防范稳定性风险

微服务架构让微服务的功能更加内聚，迭代速度更快，但是呢，增加了服务依赖复杂性，进而增大了稳定性建设难度。尽管其依赖关系复杂，但可抽象为上游服务、自身服务、下游服务三者的关系，稳定性风险防范的主要思路是防范三者的风险。

spring-session线上问题复盘

发现问题流程

1. 基础服务的CPU告警，当时对基础服务进行了重启操作，重启之后负载下降暂时恢复。
2. 10时50分dba查看到redis 实时连接数有点高超过2500，还有一些慢查询，后面redis也开始告警
3. 打印服务出现异常的网络连接，立即对服务器进行了重启操作。
4. 基础服务出现CPU告警，然后又对相关的基础服务进行重启操作。
5. 打印服务负载情况大家认为是打印服务导致了整个系统缓慢，紧急对打印服务进行了节点扩展，结果是11时30几分反馈系统能使用，整体操作上比较卡。
6. redis 服务CPU告警
7. 14时12分又开始收到用户反馈系统卡，无法正常打开页面访问，其他服务都出现相同情况，当时的现象是出现redis 的QPS急速飙升高峰到80000+
8. 根据当时的现象表现整个系统很卡，redis 的QPS很高是平时的好几倍，redis的连接数也很高快到达了5000，日志上也有出现各种redis连接超时，甚至有出现redis oom 等报错。当时大家都比较怀疑是redis出现了问题，导致系统变慢变卡，然后对redis的存储对象进行了排查，没有发现特别大的存储key，又对存储的key数量进行了排查（思路是查找出key前缀相同排名前几的key，然后去分析具体是什么操作引起的）。经过dba 的查看分析发现 spring:session:sessions 开头的key占用了将近600万，这个key主要是spring session使用redis存储产生的，非常的异常，为什么会产生这么多。