Java烘焙师

后端程序员除了写代码，也难免要写设计文档，画各种图。因此掌握各种生产力工具，是很有必要的，可以达到事半功倍的效果。下面结合楼主亲身体验，推荐一些生产力工具，欢迎探讨和补充。...

看一下官方的原文定义：翻译过来就是：反射是指一个运行中的Java程序可以检查、修改自己内部的属性，也可称之为自省。反射是Java有别于其它编程语言的一大特性。从reflection的字面意思看，就是倒影、反射，就好比你照镜子，通过倒影就能知道自己长什么样，理一理头发就能改变发型。...

首先要回答一个问题，为何要使用HBase？随着业务不断发展、数据量不断增大，MySQL数据库存在这些问题：要使用HBase，最重要的一点是rowkey行键设计，如果设计不妥，后续要改的代价非常大。下面列几个HBase rowkey设计的原则：...

背景有2种常见的多维度查询场景，分别是：带多个筛选条件的列表查询不含分库分表列的其他维度查询普通的数据库查询，很难实现上述需求场景，更不用提模糊查询、全文检索了。下面结合楼主的经验和知识，介绍初级方案、进阶方案（上ElasticSearch），大部分情况下推荐使用ElasticSearch来实现多维度查询，赶时间的读者可以直接跳到“进阶方案：将ElasticSearch添加到现有系统中”。初级方案1、根据常见查询场景，增加相应字段的组合索引这个是为了实现带多个筛选条件的列表查询的。优点

结论有以下几种Redis集群方案，先说结论：Redis cluster：应当优先考虑使用Redis cluster。codis：旧项目如果仍在使用codis，可继续使用，但也推荐迁移到Redis cluster。twemproxy：不建议使用，与codis同为proxy方案，但不如codis（twemproxy不能平滑地扩容）。客户端分片：应当禁止使用，因为扩容复杂，如果2个服务同时读写，其中一个修改了路由，另一个不修改会有问题。下面重点介绍Redis cluster和codis。Redi

先说结论：本地缓存优先选用caffeine，因为性能比guava cache快，api风格与之兼容、能轻松地平滑迁移，并且在spring/spring boot最新版本中已经是默认本地缓存了。下面展开讲讲本地缓存和Spring cache。本文讨论堆内缓存，暂不讨论堆外缓存。堆内缓存是指缓存与应用程序在一个JVM应用中，会受GC影响，一般业务层面的应用开发用不到堆外缓存。1、什么场景使用本地缓存并非所有的缓存场景，redis都适用，以下情况应当优先考虑本地缓存。数据量不大修改频率低、甚至是静态的

要在应用中做到幂等，其实并不难，本文尝试做一个系统性的总结，欢迎一起探讨。什么是幂等某个操作执行一次，跟执行多次的效果一样。幂等一词来自于数学中的幂等，即f(f(x)) = f(x)。需要保证幂等的场景查询类的读操作，天然是幂等的，多次调用不会有副作用。需考虑以下几种写操作的情况：调用下游写接口写数据库、写Redis等消息订阅和处理例子：不能给用户重复发放优惠券、现金奖励、通知等，商家更新商品时不能重复增加或减少库存。下面分别讨论这几种情况。1、调用下游写接口主要依靠下游服务保证幂

为了构建高并发、高可用的系统架构，压测、容量预估必不可少，在发现系统瓶颈后，需要有针对性地扩容、优化。结合楼主的经验和知识，本文做一个简单的总结，欢迎探讨。1、QPS保障目标一开始就要明确定义QPS保障目标，以此来推算所需的服务、存储资源。可根据历史同期QPS，或者平时峰值的2到3倍估算。压测目标示例：qps达到多少时，服务的负载正常，如平均响应时间、95分位响应时间、cpu使用率、内存使用率、消费延迟低于多少不要让任何一个环节成为瓶颈，需考虑服务实例、数据库、Redis、ES、Hbase等资源

本文介绍如何应用Canal实现异步、解耦的架构，后续有空再写文章分析Canal原理和源代码。Canal简介Canal是用来获取数据库变更的中间件。伪装自己为MySQL从库，拉取主库binlog并解析、处理。处理结果可发送给MQ，方便其他服务获取数据库变更消息，这一点非常有用。下面介绍一些典型用途。其中，Canal+MQ作为一个整体，从外界看来就是一个数据管道服务服务，如下图。Canal典型用途异构数据（如ES、HBase、不同路由key的DB）通过Canal自带的adapter，同步异构数

上一篇文章介绍了MySQL主从同步的原理和应用，本文总结了MySQL主从延迟的原因和解决办法。如果主从延迟过大，会影响到业务，应当采用合适的解决方案。MySQL主从延迟的表现先insert或update写入更新操作，再立即select查询，但是得不到最新的结果。可通过show slave status命令，结果中的Seconds_Behind_Master列，查看主从延迟的秒数。MySQL主从延迟的原因读写分离时，写操作走主库，读操作走从库，但是主库的变更还未同步至从库网络传输延迟：从库发起d

日常工作中，MySQL数据库是必不可少的存储，其中读写分离基本是标配，而这背后需要MySQL开启主从同步，形成一主一从、或一主多从的架构，掌握主从同步的原理和知道如何实际应用，是一个架构师的必备技能。楼主将在本文做总结，看这一篇就够了。1、主从同步原理主从同步架构图（异步同步）这是最常见的主从同步架构。主从同步流程（异步同步）主库把数据变更写入binlog文件从库I/O线程发起dump请求主库I/O线程推送binlog至从库从库I/O线程写入本地的relay log文件（与binlog格

按楼主的经验和知识，本文总结了应用开发中的各种存储架构，从易到难，从起步到起飞。如有不对之处，欢迎留言。1、单库：最简单的初始架构，适用于千万级以下的数据，并发量低的场景。单库、单表或单库、多个分表：之所以分表是为了给后续分库做预留准备2、分库分表、读写分离：最常见的存储架构，适用于十亿级别以下的数据，并发量大、主备高可用的场景。分库分表：对业务id（如用户id、商户id）取模，散列到各个分库的分表中读写分离：适用于读多写少的场景，利用数据库一主多从的方式，提高并发量，对主库读写，对从库只读