守株阁

何时加载类 遇到 new、getstatic、putstatic 等指令时。 对类进行反射调用的时候。 初始化某个类的子类的时候。 虚拟机启动时会先加载设置的程序主类。 使用 dynamic 动态语言支持等相关特性时。 从 Java 到 cpp 源码分析 JVM默认用于加载用户程序的ClassLoader为AppClassLoader，不过无论是什么ClassLoader，它的根父类都是java.lang.ClassLoader。在上面那个例子中，loadClass（）方法最终会调用到ClassLoader.definClass1（）中，这是一个Native 方法。 12static native Class<?> defineClass1(ClassLoader loader, String name, byte[] b, int off, int len, ProtectionDomain pd, String source); definClass1（）对应的 JNI 方法为...

数据的分类状态型数据，需要三地五中心容灾，需要强一致性，事务延迟较高。对状态型数据的操作实际上是对同一行记录进行反复操作。 流水型数据，对历史数据依赖较少，每一笔业务相对独立。 基于一定的业务理解和假设，我们可以设计出一套新的模型和存储方案，实现流水型 FO。 部署形态通常流水型 FO 要求部署三套库。 主库 LFO 库 同城 FO。承担机房级故障。 RFO 库，异地 FO 库。承担区域 数据格式8 位日期 + 1 位数据版本 + 1 位系统版本 + 3 位系统标识 + 2 位预留 + 2 位 uid + 2 位弹性位 + 8 位 sequence 设计数据格式影响几个问题： 1 当系统发生一笔流水的时候，流水应该落到哪个库里去。2 当我需要一笔流水时，我应该从哪个库里面查询这笔流水。 有关联关系的单据，如果发生弹性切换，要保证正逆向流程的单据都弹到一个库里。 流水型 FO 方案如何做到业务无感知？？？？ 流水型 FO 发生强切的时候如何保证业务业务无损？？？？

能力要素要重点建设的三种能力： 结构化的思维 结构化的工作模式 结构化的能力建设 什么是结构化structured：建立中心（问题、目标）以中心的核心要素对中心进行分解，形成分类子结构。以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；对关键分类子结构进行分析，寻找对策，制定行动计划。 同理，按照逆向的顺序，对多种杂乱的内容，进行分类、剪枝、归纳归总成一个中心，也是结构化。 案例建立结构化的中心一个业务需求，通常可以按照两个维度分解为不同的子结构： 1 当前业务需求的目标是什么？（事的维度）。 目标是快速完成上线试一试业务效果：目标事的维度为高效稳定上线。 目标是建立后续业务铺开的基础方案：目标事的维度是强架构设计下的核心与功能拆分方案。 2 为什么需要我来做？（人的维度） 是因为我工作量还有 buffer...

知识体系图谱 紧急处理原则出现问题应该第一时间恢复，恢复过程中如果有余地则要保留问题现场供后面排查定位问题，其基本步骤是： 打印堆栈信息 打印内存镜像 生成core文件 保留gc日志文件 保留业务日志文件 查看JAVA堆内存运行分配 如果有余地，可以做完以上的操作后再重启应用。 实例实例一1 查看 gc 日志，评估代际问题。2 查看访问日志，看看应用吞吐量。3 用 jstat 查看代际问题。4 把内存 dump 出来，分析数量最多的对象。5 分析代码。6 改善代码。 实例二1 统计线程总数：ps -eLf | grep java -c2 看 ulimit -u3 jstack、gcore4 改善 jvm 参数

遇到线上问题，经常陷入一个误区：一定要找到问题的根因（root cause）。但实际上对线上应用而言，最重要的是恢复可用性，所以在开发设计环境除了完成功能性需求以外，还需要加入非功能性设计的需求： 限流保护。抵挡来自突发流量冲垮整个集群。 降级保护，对调用的服务接口保持警惕，其各种因素导致不可用，可以对齐降级，从而确保核心功能可用。 削峰填谷（traffic shaping），不因突发数据来袭，造成任务消费陡增，造成调用系统的连串抖动。 这些基本的系统保护，是应对未来的各种突发不确定事件的高可用思考。 以上描述的是问题的应对机制设计，问题的发现机制，也需要结构化地考虑，体系化地建设： 发现机制，是我们的眼睛，也是基础。 监控主指标，需要找对业务的主要指标，常见的主指标一般是：RT（响应时间）、总量、成功量、失败量、成功率。 主指标有异常，还要有细分维度（即结果还可以内部 group by aggregation）。 快速恢复 根据监控快速寻找问题发生的方向和位置。 找对恢复的人、恢复的预案。 倾向于选择成本低的恢复手段。——...

1 用户需求场景分析，识别业务全景 use case。这一个阶段重点识别 actor 和 use case。 2 分析模型鲁棒图，识别出业务场景中所有的实体对象。识别边界类（类似 ui）、控制类（类似 controller）和实体类（类似model）三种类型。 3 领域划分，将所有识别出的实体对象进行分类。 比如，主订单、子订单对象和归类到交易域；买家、卖家对象可以归类到会员域。 当然，最终所有的对象是归类到十个域还是二十个域，从理论上看，可以看做一次排列组合过程。只是，我们往往可以根据以往的经验、业务知识，做一个初始的域划分（但不见得是靠谱的）。因此，我们可以认为一个域实际上是一个或多个实体对象的信息集合，并对所管理的实体对象的生命周期进行管理。 4...

全局命令查看所有键12# 查看所有键，支持 glob 风格通配符keys * 这个命令会不加区别地，做全局的键扫描，返回且只返回键。它的时间复杂度是O（N），线上环境因为无法预测键的数量，应该禁用这个命令。 看起来 redis 并没有做一个全局的 keys 的缓存，所以并没有办法优化局部性能，但即使存在一个全局的 keys 列表，对这个列表进行遍历，其时间复杂度依然是 O(N)。 键总数12# 查看所有键dbsize 这个操作的性能是 O(1)，也就意味着可以直接被线上使用。 它可以作为查询全部数据以前的预优化，至少全局的记录数量可以预先提取出来，以获得分页查询的依据。 检查键是否存在12# 确认 java 作为一个键是否存在exists java 如果存在返回 1，不存在返回...

如前文所述，Redis 自带数据类型包括：string、hash、list、set 和 zset，但它们实际上只是 redis 的外部数据类型。Redis 还自带一套内部的编码实现，可以通过以下命令查询键的实际内部编码类型： 123# 组合命令object encoding hello"embstr" string int(小于8B)/embstr(小于39B)/raw（其他） hash hashtable/ziplist list linkedlist/quicklist/ziplist set hashtable/intset zset skiplist/ziplist ziplist 对复杂数据结构几乎是万能的。他的特点是比较节省内存，但在数据元素较多的情况下性能比较容易下降。

Redis 笔记之二：toolkit标签（空格分隔）： Redisredis-server常用的配置文件内容： port 一般是 6379 logfile 日志文件（redis 的日志文件和 Kafka 不一样，和存储文件是分离的） dir Redis 工作目录（存放持久化和日志文件） daemonize 是否以守护进程的方式来启动 Redis redis 的 minor 版本号如果是奇数，则含有实验性 feature 的非稳定版本；如果是偶数，则是稳定版本。所以我们应该在生产环境使用偶数版本，而在实验性环境里使用奇数版本。 redis-clicli 有两种工作形式：interactive 和 non-interactive。 使用 redis-cli 关闭 redis 的时候，redis 会做优雅关闭的操作，优雅关闭主要包括： 断开客户端连接。 存储数据到 rdb 文件。 所以要尽量用 shutdown 命令，而不要直接 kill（待完成，kill 的分类）。 redis-benchmark基准测试工具 redis-check-aofAOF...

Redis 高性能的原因Redis 的读写性能达到 10w/s，主要基于以下原因： 数据主要放在内存中。 Redis 使用距离 OS “层次更近”的 C 语言实现。 Redis 使用单线程架构，没有很高的 lock contention。 IO 多路复用技术 Redis 的代码实现得优雅而兼顾性能 Redis 的数据结构Redis 本身是 Remote Dictionary Server 的简称，其中，老的、常见的数据结构有： 字符串 哈希 列表 set（集合） zset（有序集合） 但后来追加了几种新颖的数据机构，包括：bitmap、hyperloglog，更后来更添加了 GEO 地理信息相关的工具。 基于这些数据结构，我们可以实现一些常见的功能： 键过期，可以用来实现缓存，进而实现分布式锁。 发布订阅功能，进而实现消息系统（待尝试）。 Lua 脚本功能，可以实现自定义的 Redis 命令（待尝试）。 实现简单的事务功能，能在一定程度上实现事务特性。 提供流水线功能，能够让客户端一次性把一批命令一次性上传到 Redis 里，能够合并 IO...