3.编写整洁的代码 是否是整洁的代码，需要遵循一定的方法论，不能靠个人主观的感觉判断。推荐大家看完《代码整洁之道》这本书，遵循这里的原则。 列出一些必须要遵循的原则： 命名 做有意义的区分 区分名称，要使用读者能清洗鉴别出不同之处的方式。禁止类似customerInfo/customer、 user/userInfo、 money/moneyAmount 这种没有区分度的命名 使用可搜索的名称 例：WORK_DAYS_PER_WEEK 很容易搜索，但是数字5就无法搜索了 类名 类名和对象名应该是名词或名词短语。类名不应当是动词。正例：Customer、AddressParser；反例：Manager、Processor、Data 方法名 方法名应当是动词或者动词短语。比如：deletePage/save等 添加有意义的语境 很少有名称能自我说明，你需要良好命名的类、函数和名称空间来放置名称，给读者提供语境。如果没这么做，需要给名称添加前缀。 比如在缺少上下文的情况下，firstName、lastName、street就需要添加前缀addrFirstName、addrLastName、a....
一、数据库中间件设计思路 1.1.背景 最开始学习jdbc的时候，直接通过jdbc就能访问DB。但是这时候缺少了数据源、缺少了ORM框架，不能在生产环境使用，在后期更换DB类型时也存在很大问题。 所以出现了ORM框架。在未进行读写分离/分库分表的情况下，我们是直接在应用中通过数据源(c3p0、druid、dbcp2等)与数据库建立连接，进行读写操作，架构如下所示： ORM框架作用： 隐藏了对象的访问细节 ORM使我们构造固化数据结构变得简单易行 可以看到在操作单库单表的情况下，我们是直接在应用中通过数据源(c3p0、druid、dbcp等)与数据库建立连接，进行读写操作。 随着互联网的发展，数据规模越来越大，分库分表、读写分离成了通用的解决方案。 大部分开发人员对于访问单库的应用的架构都是很熟悉的。但是在进行读写分离/分库分表后，底层的数据库实例就会有多个，读写分离情况下一个master多个slave；分库分表的情况下，有多个不同的分库。 从应用的角度来说，除了要与多个不同的数据库建立连接，还需要处理分库分表/读写分离特定场景下的问题： 在读写分离的情况下，应用需要对读sql/写sql....
对象之间的关系就体现为类之间的关系。类之间存在不同的关系，依赖的强弱也各有不同，从强至弱依次为： 继承关系 → 组合关系 → 协作关系 继承关系 继承关系体现了“泛化-特化”的关系，父类提供更加通用的特征，子类在继承了父类的特征之外，提供了符合自身特性的特殊实现。继承关系在 UML 中使用空心三角形加实线的方式来代表子类继承父类，例如矩形类继承自形状类： 继承会导致子类与父类之间形成一种强耦合关系，父类发生任何变更，都会体现到子类中，形成所谓的“脆弱的基（父）类”。由于继承代表了一种“is”的关系，在领域建模时，父类和子类代表的其实是同一个领域概念的不同层次。 组合关系 组合关系体现了类实例之间整体与部分之间的关系，体现了“has”的概念，即一个类实例“包含了”另一个或多个类实例。组合关系体现了类概念之间的一对一、一对多和多对多关系。依据关系的强弱，组合关系又分别分为“合成（Composition）”关系与“聚合（Aggregation）”关系。前者的关系更强，例如计算机和 CPU 之间就是合成关系，因为离开了 CPU，计算机就不能正常运行；后者的关系较弱，例如计算机和键盘之间就是聚合....
一、分表键的选择 分表键即**分库/分表字段，zebra里面叫做维度，**是在水平拆分过程中用于生成拆分规则的数据表字段。Zebra 根据分表键的值将数据表水平拆分到每个物理分库中。 **拆分主要原则：**需要找到数据库表中的数据在业务逻辑上的主体，并确定大部分或者核心的数据库操作都围绕着这个主体的数据进行。可以使用该主体对应的字段作为分表键，进行分库分表。 业务逻辑上的主体，通常与业务的应用场景相关，下面的一些典型应用场景都有明确的业务逻辑主体，可用于分表键： 面向用户的互联网应用，都是围绕用户维度来做各种操作，那么业务逻辑主体就是用户，可使用用户对应的字段作为分表键； 侧重于卖家的电商应用，都是围绕卖家维度来进行各种操作，那么业务逻辑主体就是卖家，可使用卖家对应的字段作为分表键； **注意：**无论选择什么拆分键，采用何种拆分策略，都要注意拆分值是否存在热点的问题，尽量规避热点数据来选择拆分键。 1.1.多个分表键如何处理 名词解释： **主维度：**主分表键，在主维度上，数据能够增删改查； 辅维度：辅助分表键，在辅助维度上，只能进行数据查询 大部分场景下，一张表的查询条件比较单一....
一、常用命令 内存分析常用命令： // 打印每个class的实例数目,内存占用,类全名信息.live子参数加上后,只统计活的对象数量. 此时会触发FullGC jmap -histo:live <pid> > filename | head -10 // dump 内存 jmap -dump:live,format=b,file=/opt/logs/dump.hprof <pid> // 查看堆栈使用情况 jmap -head pid // 垃圾回收统计概述 jstat -gc <pid> <time> // 垃圾回收统计概述，使用空间占总空间的百分比 jstat -gcutil <pid> <time> // 用于生成java虚拟机当前时刻的线程快照 jstack <pid> 二、问题描述 我们系统中存在一个定时任务，每次执行任务时都会触发full gc，稳定复现。是一个报表计算的任务，会把原始表的数据经过加工整理汇总到指标表，涉及数据大批量插入的情况 三、排查过程 排查思路是：发生fullg....
输入top命令之后： 总共有这些指标： 每个字段具体什么意思呢？ 名称英文解释说明备注 PIDProcess Id进程IDx USERUser Name优先级 PRPriority？ NINice value虚拟镜像 VIRTVirtual Image RESResident size SHRShared Mem size SProcess Status %CPU %MEM TIME+ COMMAND
1.使用top命令查询Java进程 代码块 SQL top 定位到java进程为369 2.通过top命令定位进程包含的线程信息 代码块 SQL top -H -p 369 -d 1 -n3 查询到线程占用率最高的线程PID 为672 3.通过jstack命令查询线程堆栈 jstack 下的NID为16进制，672对应的16进制为223 代码块 SQL jstack -l 369|grep -A 20 "223" 结果内容为： 至此，可以根据代码去定位问题
1、日志中心架构图： 2、日志接入流程 第一步需要配置Category生产日志，首次生产日志，会根据Category在kafka中创建topic，日志生产完在kafka中验证
结构型 1.用例图 用例图参考： 建立用例模型首先要确定角色(Actors)，Actors表示提供或接收系统信息的人或系统，他们是与系统有交互作用的人或事务，代表一个系统的使用者或外部通信的目标。用例是系统中的一个功能单元，可以被描述为参与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者，并且显示哪个是用例的执行。 2.组件图（构件图） 是用来反映代码的物理结构。从组件图中，您可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。 3.部署图 也叫做实施图，描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。可以了解软件和硬件的物理关系以及处理节点的组件分布情况，传达了构成应用程序的硬件和软件元素的配置和部署方式。一个部署图描述了一个运行时的硬件节点，以及在这些节点上运行的软件组件的静态视图。 4.类图 类图通过显示系统的类和它们之间的关系来概述系统。类图是静态的 - 它们显示出什么交互，但不会发生什么交互。 那么属性/方法名称前加的加号和减号是什么意思呢？它们表示了这个属....
模式与操作 模式 模式可以是以下任意一种： 正则表达式：使用通配符的扩展集 关系表达式：使用运算符进行操作，可以是字符串或数字的比较测试 模式匹配表达式：用运算符～（匹配）和~!不匹配 BEGIN 语句块， pattern语句块， END语句块 awk常见命令 NF NF表示字段数量，通过分隔符分割后有多少个字段 代码块 Plain Text printf "1:2:3:4:5:4" | awk -F ":" NF==6'{print $0}' 1:2:3:4:5:4 FS FS表示输入字段分隔符，默认为空格 代码块 Plain Text printf "we are you " | awk 'BEGIN{FS="\t"} {print $1, $2, $3}' we are you RS RS 记录分隔符变量 $n : 当前记录的第n个字段，比如n为1表示第一个字段，n为2表示第二个字段。 $0 : 这个变量包含执行过程中当前行的文本内容。 ARGC : 命令行参数的数目。 ARGIND : 命令行中当前文件的位置（从0开始算）。 ARGV : 包含命令行参数的数组。 CON....