“你对架构这个词怎么理解？” emm ….. 实际上，软件架构分成 2 派。 1 软件架构的派别 组成派组成派的定义非常简洁。定义：软件系统的架构将系统描述为计算组件及组件之间的交互。 剖析定义：a. 该架构关注架构实践中的客体——软件，以软件本身为描述对象。b. 分析了软件的组成，即软件由承担不同任务的组件组成，这些组件通过相关交互，完成更高层次的计算。 决策派决策派的定义相对于组成派的定义

1. 索引索引，类似书籍的目录，可以根据目录的某个页码立即找到对应的内容。 索引的优点：1. 天生排序。2. 快速查找。索引的缺点：1. 占用空间。2. 降低更新表的速度。 注意点：小表使用全表扫描更快，中大表才使用索引。超级大表索引基本无效。 索引从实现上说，分成 2 种：聚集索引和辅助索引（也叫二级索引或者非聚集索引） 从功能上说，分为 6 种：普通索引，唯一索引，主键索引，复合索引，外键索引

Canal 源码走读canal 是什么？ 引用一下官方回答： 阿里巴巴mysql数据库binlog的增量订阅&消费组件 canal 能做什么？ 基于日志增量订阅&消费支持的业务： 数据库镜像 数据库实时备份 多级索引 (卖家和买家各自分库索引) search build 业务cache刷新 价格变化等重要业务消息 比如 LZ 目前就使用 canal 实现数据实时复制，搜索引

上周晚上，某环境 ES 出现阻塞， 运行缓慢。于是开始排查问题的过程。 开始思路：现象是阻塞，通常是 CPU 彪高，导致业务线程分配不到 CPU 时间片，或者内存吃紧，频繁 GC 导致的 STW。登录到目标服务器，由于 ES 的用户不是 LZ，因此找运维要了 root 权限，登录到服务器。sudo -i 切到 root，使用 ps -ef | grep Elasticsearch 找到该用户，然后

随着业务发展越来越快，数据量越来越多，用户也越来越多，业务出现故障的几率也越来越大，而可用性是衡量一个系统的关键指标，application 由于是无状态的，可用性很好保证，当一个应用挂掉，直接切到另一个即可，最关键的是数据库的高可用，则是最复杂的。 今天我们将尝试探讨数据库的异地多活高可用。注意，我们讨论的都是超大数据量（50TB 级别）的数据库。 第一种直接上分布式数据库，目前市面上常见的有

像我这样的菜鸟，总会有各种疑问，刚开始是对 JDK API 的疑问，对 NIO 的疑问，对 JVM 的疑问，当工作几年后，对服务的可用性，可扩展性也有了新的疑问，什么疑问呢？其实是老生常谈的话题：服务的扩容问题。 正常情况下的服务演化之路让我们从最初开始。 单体应用每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每个程序员都经历过。 RPC 应用当业务越来越大

本文旨在讲述如何使用 Java 语言实现基于 Raft 算法的，分布式的，KV 结构的存储项目。该项目的背景是为了深入理解 Raft 算法，从而深刻理解分布式环境下数据强一致性该如何实现；该项目的目标是：在复杂的分布式环境中，多个存储节点能够保证数据强一致性。 项目地址：https://github.com/stateIs0/lu-raft-kv 欢迎 star ：） 什么是 Java 版 Raf

Preface每隔一段时间，我们总要对生活做一些加法和减法，就像写代码一样，隔断时间总要重构一下，因为有了新的思考从而引入新的设计，但重构不会修改原有的功能，只会进行优化，使速度更快，消耗的资源更少，更加易读，易扩展，易维护。 对生活一样，我们虽然是程序员，但无法完全脱离人类生活（如果可以，我愿意进入计算机的主板里，完全脱离人类生活），因此，我们总要对生活进行重构。使生活的流程更好，更”合理”。

前言从来没有写年终总结的习惯，但是今年想尝试写一点年终总结。算是一点点仪式感吧。 今天主要问自己下面几个问题 2018 规划了什么？ 2018 实际做了什么？ 2018 哪些做的不好？哪些做的好？ 2019 的规划 2018 规划了什么？先回顾下 2018 年的目标： 这是我 17 年最后一天立的 flag。 那么实现的怎么样了呢？ 2018 实际做了什么？先看 flag 有没有实现

2018 即将过去，去了一趟重庆 “了结” 了 2018. 迎战 2019. 行程规划2018-12.29 早上7点飞机从杭州出发，中午 10 点到重庆。 2019-1.1 晚上 8点 45 从重庆出发，23 点半到杭州萧山机场。 很明显，跨了个年。 第一天 12-29早上4点半就起床，坐昨天晚上预约的出租车到了萧山机场，花了150，相比回来做机场大巴才65，有点肉疼。 10 点多到了重庆，用高德