ElasticSearch之数据模型构建
第1节 什么是数据模型 数据模型是抽象描述现实世界的一种工具和方法，是通过抽象实体及实体之间联系的形式，用图形化的形式去描述业务规则的过程，从而表示现实世界中事务以及相互关系的一种映射。
核心概念：
实体：现实世界中存在的可以相互区分的事物或概念称为实体。实体可以分为事物实体和概念实体。例如：一个学生、一个程序员等是事物实体。一门课、一个班级等称为概念实体。
实体的属性：每个实体都有自己的特征，利用实体的属性可以描述不同的实体。例如。学生实体的属性为姓名、性别、年龄等。
第2节 数据建模的过程数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。
概念建模阶段 概念建模阶段，主要做三件事：
客户交流
理解需求
形成实体
确定系统的核心需求和范围边界，设计实体与实体之间的关系。在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体表结构，索引，约束，甚至是存储过程都想好，没必要！因为这些东西是我们在物理建模阶段需要考虑的东西，这个时候考虑还为时尚早。概念模型在整个数据建模时间占比：10%左右。
逻辑建模阶段 逻辑建模阶段， ...
Kafka架构与实战
1. 概念和基本架构1.1 Kafka介绍Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多生产者、多订阅者，基于 zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志， 消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。主要应用场景是：日志收集系统和消息系统。 Kafka主要设计目标如下：
以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
同时支持离线数据处理和实时数据处理。
支持在线水平扩展
有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。 对于消息中间件，消息分推拉两种模式。Kafka只有消息的拉取，没有推送，可以通过轮询实 ...
Kafka源码剖析
1. Kafka源码剖析之源码阅读环境搭建首先下载源码：http://archive.apache.org/dist/kafka/1.0.2/kafka-1.0.2-src.tgzgradle-4.8.1下载地址：https://services.gradle.org/distributions/gradle-4.8.1-bin.zipScala-2.12.12下载地址：https://downloads.lightbend.com/scala/2.12.12/scala-2.12.12.msi
1.1 安装配置Gradle解压gradle4.8.-bin.zip到一个目录配置环境变量，其中GRADLE_HOME指向gradle解压到的根目录，GRADLE_USER_HOME指向 gradle的本地仓库位置。
PATH环境变量：
进入GRADLE_USER_HOME目录，添加init.gradle，配置gradle的源：init.gradle内容：
allprojects {
repositories {
maven { url 'https://maven.aliy ...
Kafka集群与运维
1. 集群应用场景第1节 消息传递Kafka可以很好地替代传统邮件代理。消息代理的使用有多种原因（将处理与数据生产者分离，缓冲未处理的消息等）。与大多数邮件系统相比，Kafka具有更好的吞吐量，内置的分区，复制和容错功能，这使其成为大规模邮件处理应用程序的理想解决方案。根据我们的经验，消息传递的使用通常吞吐量较低，但是可能需要较低的端到端延迟，并且通常取决于Kafka提供的强大的持久性保证。在这个领域，Kafka与ActiveMQ或 RabbitMQ等传统消息传递系统相当。
第2节 网站活动路由Kafka最初的用例是能够将用户活动跟踪管道重建为一组实时的发布-订阅。这意味着将网站活动（页面浏览，搜索或用户可能采取的其他操作）发布到中心主题，每种活动类型只有一个主题。这些提要可用于一系列用例的订阅，包括实时处理，实时监控，以及加载到Hadoop或脱机数据仓库系统中以进行脱机处理和报告。活动跟踪通常量很大，因为每个用户页面视图都会生成许多活动消息。
第3节 监控指标Kafka通常用于操作监控数据。这涉及汇总来自分布式应用程序的统计信息，以生成操作数据的集中。
第4节 日志汇总许多人使用Ka ...
Kafka高级特性解析下
1. 分区1.1 副本机制Kafka在一定数量的服务器上对主题分区进行复制。当集群中的一个broker宕机后系统可以自动故障转移到其他可用的副本上，不会造成数据丢失。
—replication-factor 3 1leader+2follower
将复制因子为1的未复制主题称为复制主题。
主题的分区是复制的最小单元。
在非故障情况下，Kafka中的每个分区都有一个Leader副本和零个或多个Follower副本。
包括Leader副本在内的副本总数构成复制因子。
所有读取和写入都由Leader副本负责。
通常，分区比broker多，并且Leader分区在broker之间平均分配。
Follower分区像普通的Kafka消费者一样，消费来自Leader分区的消息，并将其持久化到自己的日志中。允许Follower对日志条目拉取进行批处理。
同步节点定义：
1. 节点必须能够维持与ZooKeeper的会话（通过ZooKeeper的心跳机制）
2. 对于Follower副本分区，它复制在Leader分区上的写入，并且不要延迟太多
Kafka提供的保证是，只要有至少一个同步副 ...
Kafka高级特性解析(上)
1. 生产者1.1 消息发送1.1.1 数据生产流程解析
Producer创建时，会创建一个Sender线程并设置为守护线程。
生产消息时，内部其实是异步流程；生产的消息先经过拦截器（）->序列化器->分区器，然后将消息缓存在缓冲区（该缓冲区也是在Producer创建时创建）。
批次发送的条件为：缓冲区数据大小达到batch.size或者linger.ms达到上限，哪个先达到就算哪个。
批次发送后，发往指定分区，然后落盘到broker；如果生产者配置了retrires参数大于0并且失败原因允许重试，那么客户端内部会对该消息进行重试。
落盘到broker成功，返回生产元数据给生产者。
元数据返回有两种方式：一种是通过阻塞直接返回，另一种是通过回调返回。
1.1.2 必要参数配置
配置条目的使用方式：
配置参数：
1.1.3 序列化器
由于Kafka中的数据都是字节数组，在将消息发送到Kafka之前需要先将数据序列化为字节数组。序列化器的作用就是用于序列化要发送的消息的。
Kafka使用 org.apache.kafka.common.serializa ...
代码之丑
开篇词 | 这一次，我们从“丑”代码出发案例一代码public void approve(final long bookId) {
...
book.setReviewStatus(ReviewStatus.APPROVED);
...
}
逻辑这是在一个服务类里面写的，它的主要逻辑就是从仓库中找出一个作品，然后，将它的状 态设置为审核通过，再将它存回去。
原因审核的状态是作品的一个内部状态，为什么服务需要知道它呢？也就是说，这 里通过 setter，将一个类的内部行为暴露了出来，这是一种破坏封装的做法。
改进public void approve(final long bookId) {
...
book.approve();
...
}
这段代码，完全是因为这里用到了 setter。setter 的出现，是对于封装的破坏，它把一个类内部的实现细节暴露了出来。面向对象的封装，关键点是行为，而使用 setter 多半只是做了数据的聚合，缺少了行为的设计，这段代码改写后的 approve 函数，就是这里缺少的行为。
再扩展一步，setter ...
从零开始学架构第二讲
架构设计的历史背景一、机器语言（1940 年之前）最早的软件开发使用的是“机器语言”，直接使用二进制码 0 和 1 来表示机器可以识别的指令和数据。例如，在 8086 机器上完成“s=768+12288-1280”的数学运算，机器码如下：
101100000000000000000011
000001010000000000110000
001011010000000000000101
不用多说，不管是当时的程序员，还是现在的程序员，第一眼看到这样一串东西时，肯定是一头雾水，因为这实在是太难看懂了，这还只是一行运算，如果要输出一个“hello world”，面对几十上百行这样的 0/1 串，眼睛都要花了！
看都没法看，更何况去写这样的程序，如果不小心哪个地方敲错了，将 1 敲成了 0。
归纳一下，机器语言的主要问题是三难：太难写、太难读、太难改！
二、汇编语言（20 世纪 40 年代）为了解决机器语言编写、阅读、修改复杂的问题，汇编语言应运而生。汇编语言又叫“符号语言”，用助记符代替机器指令的操作码，用地址符号（Symbol）或标号（Label）代替指令或操作数的地址。
例如，为了完成 ...
从零开始学架构第一讲
一、架构到底是指什么？对于技术人员来说，“架构”是一个再常见不过的词了。我们会对新员工培训整个系统的架构，参加架构设计评审，学习业界开源系统（例如，MySQL、Hadoop）的架构，研究大公司的架构实现（例如，微信架构、淘宝架构）……虽然“架构”这个词常见，但如果深究一下“架构”到底指什么，大部分人也许并不一定能够准确地回答。例如：
架构和框架是什么关系？有什么区别？
Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪个架构呢？
微信有架构，微信的登录系统也有架构，微信的支付系统也有架构，当我们谈微信架构时，到底是在谈什么架构？
要想准确地回答这几个问题，关键在于梳理几个有关系而又相似的概念，包括：系统与子系统、模块与组件、框架与架构。
二、系统与子系统我们先来看维基百科定义的“系统”。
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。
我来提炼一下里面的关键内容：
关联：系统是由一群有关联的个体组成 ...
从零开始学架构第五讲
一、复杂度的来源之一高可用参考维基百科，先来看看高可用的定义。
系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。
这个定义的关键在于“无中断”，但恰好难点也在“无中断”上面，因为无论是单个硬件还是单个软件，都不可能做到无中断，硬件会出故障，软件会有 bug；硬件会逐渐老化，软件会越来越复杂和庞大……
所以，系统的高可用方案五花八门，但万变不离其宗，本质上都是通过“冗余”来实现高可用。通俗点来讲，就是一台机器不够就两台，两台不够就四台；一个机房可能断电，那就部署两个机房；一条通道可能故障，那就用两条，两条不够那就用三条（移动、电信、联通一起上）。高可用的“冗余”解决方案，单纯从形式上来看，和之前讲的高性能是一样的，都是通过增加更多机器来达到目的，但其实本质上是有根本区别的：高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。
通过冗余增强了可用性，但同时也带来了复杂性，我会根据不同的应用场景逐一分析。
二、计算高可用这里的“计算”指的是业务的逻辑处理。计算有一个特点就是无论在哪台机器上进行计算，同样的算法和输入数据，产出的结 ...
从零开始学架构第四讲
一、复杂度的来源之一高性能对性能孜孜不倦的追求是整个人类技术不断发展的根本驱动力。例如计算机，从电子管计算机到晶体管计算机再到集成电路计算机，运算性能从每秒几次提升到每秒几亿次。但伴随性能越来越高，相应的方法和系统复杂度也是越来越高。现代的计算机 CPU 集成了几亿颗晶体管，逻辑复杂度和制造复杂度相比最初的晶体管计算机，根本不可同日而语。
软件系统也存在同样的现象。最近几十年软件系统性能飞速发展，从最初的计算机只能进行简单的科学计算，到现在 Google 能够支撑每秒几万次的搜索。与此同时，软件系统规模也从单台计算机扩展到上万台计算机；从最初的单用户单工的字符界面 Dos 操作系统，到现在的多用户多工的 Windows 10 图形操作系统。
当然，技术发展带来了性能上的提升，不一定带来复杂度的提升。例如，硬件存储从纸带→磁带→磁盘→SSD，并没有显著带来系统复杂度的增加。因为新技术会逐步淘汰旧技术，这种情况下我们直接用新技术即可，不用担心系统复杂度会随之提升。只有那些并不是用来取代旧技术，而是开辟了一个全新领域的技术，才会给软件系统带来复杂度，因为软件系统在设计的时候就需要在这些技术之 ...
从零开始学架构第三讲
一、架构设计的误区关于架构设计的目的，常见的误区有：
因为架构很重要，所以要做架构设计
这是一句正确的废话，架构是很重要，但架构为何重要呢？
例如：不做架构设计系统就跑不起来么？
其实不然，很多朋友尤其是经历了创业公司的朋友可能会发现，公司的初始产品可能没有架构设计，大伙撸起袖子简单讨论一下就开始编码了，根本没有正规的架构设计过程，而且也许产品开发速度还更快，上线后运行也还不错。
例如：做了架构设计就能提升开发效率么？
也不尽然，实际上有时候最简单的设计开发效率反而是最高的，架构设计毕竟需要投入时间和人力，这部分投入如果用来尽早编码，项目也许会更快。
例如：设计良好的架构能促进业务发展么？
好像有一定的道理，例如设计高性能的架构能够让用户体验更好，但反过来想，我们照抄微信的架构，业务就能达到微信的量级么？肯定不可能，不要说达到微信的量级，达到微信的 1/10 做梦都要笑醒了。
不是每个系统都要做架构设计吗
这其实是知其然不知其所以然，系统确实要做架构设计，但还是不知道为何要做架构设计，反正大家都要做架构设计，所以做架构设计肯定没错。
这样的架构师或者设计师很容易走入生搬硬套业界 ...
