爱喝咖啡的程序员的博客

StringBuilder和StringBuffer都继承了AbstractStringBuilder，AbstractStringBuilder内有两个非常重要的变量，分别是：// 用于存储字符的容器char[] value; // 已存储的字符数量int count; 注意，value没有加上final，也就是说，它是可变的，这点与String不同。StringBuilder与StringBuffer自身的append()方法内都使用了继承自AbstractStringBuilde

Mysql主从复制 一. 为什么要做主从复制二. 主从复制过程相关概念2.1 binlog文件一. 为什么要做主从复制确保数据安全让其它服务器成为主服务器的数据热备。当主服务器故障后，可以迅速的将从服务器切换成主服务器，不仅可以尽可能地保证数据不丢失，而且可以快速的恢复整套数据库系统，对外持续提供服务。实现读写分离读写分离的好处不仅在于请求压力分流、降低单台服务器的磁盘的IO访问频率，还在于写请求导致锁行或锁表后，读请求能正常对外提供服务。二. 主从复制过程相关概念2.1 binl

一. 数据准备有一张用户信息表(account)，有id、用户名(username)、年龄(age) 三个字段。以id作为主键，创建主键索引。以username创建普通索引。二. Innodb的实现1. 主索引树Innodb使用B+树作为索引结构，主索引树的特点是数据文件和主索引存放在一起。如图所示，主索引树的叶子节点中不仅包含主键(id)，还包含了完整的数据文件(username、age)，这种索引被称作"聚集索引"。由于数据需要依靠主键才能找到存储的位置，因此

一. 问题分库分表后，多个数据库存在相同的数据表，那么在插入数据时，主键id如何保证唯一呢？二. 解决方案1. 新增一台专门用于创建id的数据库全局范围内新增一台数据库，专门用于创建和提供主键id。其它数据库表在插入数据之前，首先向这台数据库插入一台数据，通过主键自增的方式，获得一个id，接着再插入到自己的数据表内。缺点：1.需要额外创建数据库实例。2.由于所有涉及到创建主键id的写请求操作都需要经过这台数据库，因此请求压力较高，无法满足大并发的场景。适用场景：写请求并发小，写入数据

一. 为什么在分库分表的场景下需要扩容需要为数据库集群考虑扩容的原因一般有如下两点:1. 数据库所在服务器的磁盘空间不足。(当然也可以加磁盘)2. 读写请求并发量超过了数据库集群能承载的极限。二. 如何扩容首次进行数据库规划时，尽可能地考虑极限情况。起初可能租用地服务器数量较少，但是我们可以在每一台服务器上部署尽可能多地数据库实例，这点是方便后期扩容的关键。举个例子，比如刚开始我们只租用了4台服务器，但每台服务器上部署了8个数据库实例和32张数据表。假如使用Mysql数据库，

一. 需要长时间停机的迁移方案迁移过程:1. 将业务服务停机(比如使用Tomcat容器，不在对外提供服务)2. 启动多个分库分表服务，从单库单表的DB中抽取数据，并发送至数据库分库分表中间件，接着由中间件将数据写入到分库分表的DB中。这个过程所耗费的时间与数据量、分库分表服务的个数、是否使用多线程等因素相关。3. 通过修改配置的方式，断开业务服务与单库单表DB的连接，使业务服务连接到数据库分库分表中间件上，并重启业务服务。缺点：整套迁移流程需要一气呵成，当单库单表的数据量较大时，

分布式锁一. Zookeeper1.1 zk有哪些使用场景？一. Zookeeper1.1 zk有哪些使用场景？

目录一. 前言二. 分布式基础问题一. 前言本文是我学习石杉老师所讲的Java面试突击课程时所做的笔记。二. 分布式基础问题为什么要将系统进行拆分？不易维护(项目太重)记得刚刚参加工作时，第一次接触到的大型产品是公司购买的蓝凌OA系统，这套产品涵盖了日常办公使用的申请、审批工作流、报表、后台管理以及门户等等功能。整个产品通过几十万行代码支撑，不仅有后端、还包含了前端代码以及各种脚本、模板文件，由于项目巨大，报错后不容易定位错误位置，而且每次希望定制某项功能时，非常担心修改后，牵一发而动全身

Redis进阶篇一. Redis与系统高并发之间的关系二. Redis单机的瓶颈三. Redis如何支撑超过10万QPS的并发量四. Redis replication核心机制一. Redis与系统高并发之间的关系想要设计一套能承载数十万甚至上百万QPS的系统，光凭Redis是远远不够的，Redis只不过是支撑高并发的大型缓存架构中的一个非常重要的环节。比如系统底层的缓存中间件使用Redis，再加上良好的缓存架构设计(多级缓存架构，热点缓存等)的共同作用下，才能支撑数十万甚至上百万的高并发。二. Re