数据库的瓶颈问题解决（主从分离）与多数据源切换
数据库的瓶颈问题解决（主从分离）与多数据源切换业务中，数据库的设计是极为重要的一环，在高并发的业务中，我们可以采用集群部署来缓解请求和逻辑处理的压力，但是在数据库的层面却不行，Oracle、Mysql等数据库的吞吐量很高，但是依旧有阈值，我们不能奢求单库能解决所有的问题，假设遇到了数据库的瓶颈问题，我们可以采用怎样的手段呢 想要数据库达到瓶颈（SQL执行效率明显变慢），其实是很困难的，我们在程序的设计中基本都会使用到数据库连接池控制数据连接，但当业务量提升之后，连接池若是经常达到饱和便容易产生阻塞，我们不得不开放更多的连接数，随之而来的便是数据库承载了更多的并发，解决问题的主要方式有三： 更细的划分业务逻辑，将高频业务表单独分离开来，并通过定期清理的方式减小查询的执行时间，将不同的数据库请求分发到不同服务器的不同库，可以一定程度下解决上文所述的问题，但是应以数据库的设计性为前提，绝对不能牺牲原有设计合理的数据结构将其进行拆分，得不偿失
2019-08-29鱼鱼
数据库的存储过程、触发器和一些语法
数据库的存储过程、触发器和一些语法本篇文章讲述基于MySQL的存储过程触发器和一些相关的语法 在数据库中，存储过程是指将复用度很高并且不需要通过程序进行预编译的的SQL语句预先写好存放起来（此处所指的为用户定义在数据库中的存储过程），在需要时直接通过call调用 先看一个例子（注意，这不是创建存储过程的语句）： 其中使用了日期相关的函数，DATE_SUB(CURDATE(),INTERCAL 10 DAY)代表当前时间前推十天 这个存储过程作用是查出十天前的数据然后将其删除 MySQL默认的分隔符是" ; "，这样一来定义存储过程就会因为 ; 被打断，所以在定义存储过程前后需要修改分隔符，使用DELIMITER关键字跟随分隔符，实际创建存储过程语句为：
![数据库的存储过程、触发器和一些语法]()
2019-06-12鱼鱼
多线程应用提高(II) 线程池
多线程应用提高(II) 线程池项目中，当发生并行操作时，一般都会用到线程池处理多线程任务，线程池的规则类似于数据库连接池，在此不予赘述 jdk自带线程池，此处主要讲述Spring框架自带的线程池ThreadPoolTaskExecutor 通过实现Runnable和Callable接口实现一个线程任务，从而能放入Executor进行线程管理 其中，Callable可以理解为带有返回值的Runnable，并且Callable需要实现的方法不是run()而是call()，该方法返回一个泛型对象 当我们把一个需要返回值的线程任务放进线程池后，线程池会返回一个Future对象，借助该对象，我们可以调用get()方法获取线程的状态，调用get()会阻塞当前线程直到返回结果
2020-02-25鱼鱼
多线程应用提高(I) 多线程常见问题、常用方法和关键字
多线程应用提高(I) 多线程常见问题、常用方法和关键字我们一般熟识的创建多线程方式即为继承Thread类或是实现Runnable接口，重写run()方法，还有创建线程池实现 手动定义一个线程任务（作为内部类）的方法现在已经不被提倡，所以遇到可能存在并发的复杂任务时，一般采用线程池来实现 一些设计并发常用并且容易被混淆的方法们： static sleep() : Thread类的静态方法，阻塞当前正在线程，不释放锁； wait() : 当前线程暂停，并释放锁且暂时无法重新获得锁，必须绑定当前对象内容锁（如使用Synchronized的同步块），知道其他线程调用notify()/notifyAll()才有机会获得锁继续执行； yield() : 当前线程暂停，此时时间片分配给其他线程，但是不会分配给优先级更低的线程；
![多线程应用提高(I) 多线程常见问题、常用方法和关键字]()
2019-12-07鱼鱼
算法：动态规划解法及例题
算法：动态规划解法及例题经历过很多算法题，其中最常见的解题方法便是动态规划 动态规划（dynamic programming,即DP)，是一种常见的求解最优解的方案，他通过将复杂的问题拆分为单阶段的小问题求解，核心思想是递推，通过简单基础的解一步步接近最优解 对于一个算法问题，总有一个相对令人满意的解，但却不一定是我们想要的最优解，譬如在解决动态规划中最经典的背包问题时，有些人首先想到简单省心的贪心算法，取价值最高或是性价比最高的物品组合，这种方案得到的很有可能是最优解，但贪心的算法并不适用于动态规划领域，若是物品中恰好有能将背包塞得很满的组合，而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案，而很少是真正的最优，这一点请务必斟酌
2020-03-11鱼鱼
待办事宜
待办事宜2018-10-18 解决XSS攻击问题（v-html） 针对缺省有所设置(blog:page等) 添加新增按钮 添加置顶 解决日志编辑首行出现空格 开发射线：一个匿名交流板 留言 联系方式 可回复 筑楼 时限性 超时关闭 匿名 默认匿名 字典： 可标注，添加富文本新组件字典（视情况添加 工作量难以预估 可考量在全网） 字典包括 可见性（待定），条目，解释，相关词条 必须可编辑 添加不同风格 参照http://www.unconstraint.cn/，github两种风格可切换 流动 简约 重金属 使用图床存储较大的图片（RECOMMEND：使用新浪微博）
![待办事宜]()
2019-03-24鱼鱼
排坑指南-异步操作HttpServletRequest丢失Cookie
排坑指南-异步操作HttpServletRequest丢失Cookie遇到了一个很奇怪的bug：请求鉴权失败，因为通过Request对象获取到的Cookie中没有数据 经过debug调用request.getCookies()方法返回了null值，但是header属性的cookie却能拿到用户的有效cookie(request.getHeader("cookie"))，其中缘由，且慢慢道来 我们可以在web项目中通过Request对象很方便的获取Cookie对象： 但其内部实现其实有一层缓存逻辑，从名为"cookie"的请求头中读取并处理数据转为Cookie对象并不是个省时事，在org.apache.catalina.connector.Request类中可以看到如下代码实现：
2020-11-11鱼鱼
MYSQL的索引、引擎的实现原理和应用
MYSQL的索引、引擎的实现原理和应用本篇主要介绍数据库MySQL的索引实现原理，包括B+ Tree的原理，顺带提到了数据库的常用引擎 我们常见的数据库引擎就是InnoDB，还有另外一个常见一个引擎叫做MyISAM，这里着重介绍着两个引擎，执行show engines，可见MySQL所有的引擎如下： InnoDB采用行级锁，不会记录表中的数据个数，支持外键，高并发下使用事务的首选引擎，也是5.5之后MySQL的默认引擎（之前采用MyISAM），可以通过bin-log日志回滚数据，所以它比较适合处理数据量大的数据 PS：InnoDB最初不支持全文索引，在MySQL 5.6版本后添加了支持 MyISAM跟InnoDB截然相反，它采用表锁，记录了表的条目数，SELECT COUNT可以直接查看表中数据个数，支持FULLTEXT索引，不支持外键和事务，不能进行数据恢复操作，他比较适合频繁插入的数据，或是读操作远大于写操作时
2019-09-15鱼鱼
CAT的使用和原理简介
CAT的使用和原理简介开发中刚好碰到了CAT的应用，利用这篇文章总结一下
![CAT的使用和原理简介]()
2019-08-07鱼鱼
分布式系统中的一致性算法和问题解决
分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同，需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统，他们的数据一致性算法不尽相同，例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法，而最近流行的Consul是raft算法，不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制，利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法，以便于在不同的业务环节上有着各自更贴切的处理 ps：有种观点是一致性算法不是很准确，因为replica也能保证数据某种程度上具有一致性，有人称之为共识算法
2021-03-13鱼鱼
ELK全家桶基本使用（I）文件收集Filebeat
ELK全家桶基本使用（I）文件收集FilebeatFilebeat是Elastic中的轻量文件收集系统，相比于功能更强悍的Logstash，当我们需求很单一，读取文件内容且对文件内容没有过多复杂处理时，最好使用FileBeat取代Logstash，以免造成不必要的内存开销 文档链接 Filebeat负责收集文件并发送给下游服务 核心行为包含输入、处理过滤和输出 当然也有集成好配置的模块，通过模块与Es和Kibana链接可以直接在Kibana上看到组件的可视化 同时不难看出Filebeat其实对数据库的支持不是很健壮 截止7.6版本，开源的Filebeat可支持以下几种消息输入类型： log 用得最多的输入类型； stdin 标准的输入，从process或是piepline读取（可理解为脚本运行通道直接输入），一旦配置了这种input方式，其他 input将不再生效文档地址；
2020-03-16鱼鱼
IO多路复用模型：select、poll、epoll对比
IO多路复用模型：select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型，譬如网络请求的socket IO，在数据返回前，相应的线程或是进程将会一直 阻塞直到数据返回，比较直接的处理便是针对IO流一对一的监听，但在IO返回前，相应的系统资源会平白无故的浪费，这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO，就能实现对系统资源的更好利用，在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用，在Linux系统中，实现IO多路复用的方式（从古老到新）有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别
2020-08-11鱼鱼
