分布式系统一致性的分类
分布式系统一致性的分类在分布式系统中的CAP理论中有C(一致性)，大郅表示分布式系统中节点状态或数据具有一致的特性 但一致性有着不同的分类，例如常见的用于取代CAP理论的BASE中的E，最终一致性，不同于强一致性，他强调着事务最终状态趋于一致，但中间态可能不一致，利用此篇文章总结一下分布式系统的一致性分类 根据实际系统的要求，分布式系统的一致性可以大致分为四类： 严格一致性 强一致性（线性一致/原子一致） 顺序一致性 弱一致性（最终一致性） 一个理想概念上的一致性，节点间数据完全一致，对外可表现为单个节点 由于网络延迟和通信等因素的存在，现实中这种一致性不可能存在 强一致性要求在全局时钟相同的条件下，对任何节点的读都相同且等于最后一次写成功的数据，这也就意味着仅仅在所有节点同步到数据后才会被标记为同步成功
2021-03-13鱼鱼
MySQL tips
MySQL tips一些日常接触到的MySQL优化tips，比较散乱 假设有一个用户表，对于一句很简单的查询语句： 假设name与age字段均有单列索引，容易想到的是，MySQL应该会分别走两次索引，并将其结合起来，EXPLAIN也是如此，大多数时候MySQL会进行优化，我们可能会看到EXPLAIN的结果中有Using union或Using soft union，这是MySQL针对OR做了隐性的优化，但当SQL复杂或数据极端情况下，这一语句极容易变成全表扫描，偶尔使用联合索引可能解决问题，更多情况则是MySQL“昏了头”，即使OR条件均涉及数据条数不多，依旧没能在查询语句中使用索引，此时应调整为UNION语句(可以权衡一下重复及顺序是否有影响，可以使用更快的UNION ALL)：
2021-01-13鱼鱼
什么是web服务器？什么是web应用服务器？容器、以及服务器概念的区分（萌新向）
什么是web服务器？什么是web应用服务器？容器、以及服务器概念的区分（萌新向）本文主要是为了帮助萌新理解在web开发时遇到的关于web工作原理的疑问，由于本人水平十分有限，所以本文仅作为一般性参考，如有错误，欢迎批评指正OVO 首先说明的是，我们所谓的web服务器并不是物理上的服务器，而是建立在物理服务器上的一个web应用的运行环境，是一个软件服务器 这就好比前后端分离开发时，后端模块在物理服务器上的JVM，前端也需要一个“运行环境”进行工作，那么web服务器端概念就应运而生了，大概就好比下图 上图中拥有VUE经典的原谅色的web服务器就是我们前端运行的地方，可见web服务器的主要作用是给前端一个合理的运行环境，其实不只是看起来那么简单，web服务器还要处理代理、反向代理、跨域、并支持并发等等
2019-06-16Agostino
算法1
算法1给定 n 个非负整数表示每个宽度为 1 的柱子的高度图，计算按此排列的柱子，下雨之后能接多少雨水 上面是由数组 [0,1,0,2,1,0,1,3,2,1,2,1] 表示的高度图，在这种情况下，可以接 6 个单位的雨水（蓝色部分表示雨水） 木板组成水桶装水，定义高度为一数组，间隔为1，求水桶最大容量如[1,5,1,2,6,3]为15，解题思路：自两边木板向中间遍历求容量，每次相对短的木板向内移动，共比较n-2次 将水灌满，求灌满后的高度，其实就是从最高点向左右两个方向向中间遍历，依次求经过的最大值，这样一来就是从最高点向两侧递减的，再减去柱子原高度即可 容易理解的想法还有按高度分层计算，但是时间复杂度过高
2019-03-14Sherlock
Redis原理-源码解析：数据结构3 hash
Redis原理-源码解析：数据结构3 hash 所有原理实现基于Redis版本6.0.9 hash在Redis中可以认为是套了一层的string，当然，对hash来说没有数字类型 让我们依旧通过基本命令看看hash的基本数据结构实现 在set方法中我们看到了hash的初始创建过程，一个hash最开始是zipist 想要了解ziplist可以看Redis原理-源码解析：数据结构2 list ，是为节省内存而生的链表格式 所以其实在使用ziplist时其查询的时间复杂度不是遵循hash的近似O(1)，而是O(n)，但是在数据量不大时，这种性能的损失微乎其微，并且能预见到大多数使用hash的场景都不会存储过多的字段 所以优先使用了更节省内存空间的ziplist
2020-11-29鱼鱼
动态路由数据源（多租户）解决方案
动态路由数据源（多租户）解决方案当下有很多服务都使用了多数据源，或是出于跨库查询或是分库分表、读写分离等，多数据源解决方案早已不是稀罕事 常见的解决方案包括使用多数据源框架(例如Shareding-Jdbc)、在数据库端做代理（例如MYCAT）、对于固定的几个数据源连接，也可以直接手动配置多个数据源，这种相关处理有很多源码，我在github上也有简单的实现：fishstormX/dynamicDataSource: 动态数据源的实现，基于maven自定义多模块骨架 Spring Boot2.0.x，本文实现的是动态数据源，主要为了解决 多租户问题（不同的用户群组有不同的数据源和配置，强调数据的隔离性） 本文技术能实现的是动态数据源，基于Spring框架，即能够将注入的Datasource根据租户不同使用不同的来源，同时根据租户增减动态的增删和缓存数据源（增是因为会有新增租户可能使用到项目启动后的数据源，减是因为租户数不可预料，不可直接缓存所有的数据源）
2021-01-07鱼鱼
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解CAT是美团点评的一个基于Java开发的异常和性能监控项目，github地址：https://github.com/dianping/cat 本篇文章不是对CAT本身的源码拆解，而是基于本人依赖CAT client开发的代理项目进行拆解，但是并不会纰漏任何技术细节 CAT当前已有很多不同语言的Client，当然暂且是不 CAT本身是通过CAT client收集数据并上报至CAT server，server会进行并，共有六种常见数据格式：Transaction、Event、Problem、Metric、HeartBeat、调用链标记，其实如果不考虑复杂的处理（譬如Metric是可以基于指标生成折线图，Problem可以根据具体的异常类型追溯到相应的会话Track）除去Transaction剩余的数据格式都可以理解为特殊的Event
2020-07-19鱼鱼
Spring MVC源码和设计思想3 拦截器HandlerInterceptor
Spring MVC源码和设计思想3 拦截器HandlerInterceptor系列的源码基于Java Spring 框架5.1.x版本 HandlerInterceptor是SpringMVC框架提供的独有拦截器，本身只是一个接口，提供了三个方法，方法作用情况我已标出： 有关方法执行的具体时机，可以参考Spring MVC源码和设计思想1 DispatcherServlet文中的代码 上面使用到了default关键字，default关键字是Java 8的新特性之一（之前只有用在switch中），通过default可以在接口中定义一个方法的方法体，从而使该方法不必被强制继承 Java8中也添加了static用于修饰接口方法 主要是为了考虑接口重复方法的设计，比如多个类继承与同一个接口并且需要定义相同的方法实现时，用过default或static可以避免产生重复代码
![Spring MVC源码和设计思想3 拦截器HandlerInterceptor]()
2019-06-09鱼鱼
常见树形结构
常见树形结构树形结构 相关术语 结点(Node)：表示树中的数据元素，由数据项和数据元素之间的关系组成 在图中，共有10个结点 结点的度(Degree of Node)：结点所拥有的子树的个数，在图中，结点A的度为3 树的度(Degree of Tree)：树中各结点度的最大值 在图中，树的度为3 叶子结点(Leaf Node)：度为0的结点，也叫终端结点 在图中，结点E、F、G、H、I、J都是叶子结点 分支结点(Branch Node)：度不为0的结点，也叫非终端结点或内部结点 在图中，结点A、B、C、D是分支结点 孩子(Child)：结点子树的根 在图中，结点B、C、D是结点A的孩子
2019-03-15鱼鱼
算法：动态规划解法及例题
算法：动态规划解法及例题经历过很多算法题，其中最常见的解题方法便是动态规划 动态规划（dynamic programming,即DP)，是一种常见的求解最优解的方案，他通过将复杂的问题拆分为单阶段的小问题求解，核心思想是递推，通过简单基础的解一步步接近最优解 对于一个算法问题，总有一个相对令人满意的解，但却不一定是我们想要的最优解，譬如在解决动态规划中最经典的背包问题时，有些人首先想到简单省心的贪心算法，取价值最高或是性价比最高的物品组合，这种方案得到的很有可能是最优解，但贪心的算法并不适用于动态规划领域，若是物品中恰好有能将背包塞得很满的组合，而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案，而很少是真正的最优，这一点请务必斟酌
2020-03-11鱼鱼
网络时延、异步IO、Pipeline
网络时延、异步IO、Pipeline通过使用多线程是能提高网络延迟带来的负面效应的，也就是在IO密集型的应用中（尤其是网络IO密集应用中），通过异步操作或能显著提高性能，本篇讨论相关问题 并不是异步（多线程）定能提高性能，有这种讨论也是发现经常有人会滥用多线程 通常会有一种说法：如果想要采用多线程的来执行一段任务，为了提高性能，假设服务器中有N个核心，推荐在CPU密集型的应用中启用N个线程，而在IO密集型的任务中启用2*N个线程 本人不是很认同此种说法，他只能代表一个大致的度量，在实际应用中几乎可以说完全不准确，一般来说，权衡系统资源与性能后，前者可能需要更少的线程数，而后者根据实际情况也许适宜分配更多的线程数 这个概念大家一般都不是很陌生，在此再次科普下：所谓IO密集型任务，即是任务的资源消耗多集中在系统IO上，这里的IO本来包括磁盘IO和网络IO等，但是磁盘IO涉及文件句柄操作等系统限制不在本篇讨论，所以此篇文章所提主要指网络IO，高网络IO也是绝大多数web应用的特性
2021-04-21鱼鱼
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听查看源码的顺序就见仁见智了，比较普遍的做法是从IoC入手，了解容器注入的每一个环节，掌握大致的流程 由于使用的是Spring，所以在这里我们引入比较古老的xml配置文件进行bean的配置，首先定义一个bean: 配置描述bean的xml，核心只有一行： 这样一来就可以使用BeanFactory这个容器来注入bean并使用了： 本来有封装好的XmlBeanFactory，这一类现在已经被弃用了，所以采用了他的父类DefaultListableBeanFactory;当然，也可以使用更加方便和常用的ApplicationContext： 当然从xml文件读取bean的配置只是其中一种目前用的不多的加载方式，还有基于包扫描等加载bean的方法，此处仅为理解IoC的基本使用
2020-08-04鱼鱼
