sudotty / reading_note Goto Github PK

View Code? Open in Web Editor NEW

8.0 8.0 0.0 0 B

笔记

reading_note's People

Contributors

Stargazers

Watchers

reading_note's Issues

JavaScript里面的奇葩知识

https://mp.weixin.qq.com/s/sMKiQy4BeLCSGILvxArUDw

MySQL查询的自动完成引擎

https://github.com/stevenmiller888/ts-mysql-autocomplete

马斯克的学习方式

问题：你是如何学得这么快的？

埃隆-马斯克：把知识看作是一种语义树，这一点很重要--在你进入叶子/细节之前，确保你理解基本原理，即树干和大树枝，否则它们就没有什么可挂念的了。

计算机开放电子书归档

https://github.com/wizardforcel/it-ebooks-blog

一些关于采纳微服务的想法

https://www.pixelstech.net/article/1599277439-Some-thoughts-about-microservice-adoption

事务

PostgreSQL实际上将每一个SQL语句都作为一个事务来执行。如果我们没有发出BEGIN命令，则每个独立的语句都会被加上一个隐式的BEGIN以及（如果成功）COMMIT来包围它。一组被BEGIN和COMMIT包围的语句也被称为一个事务块。

也可以利用保存点来以更细的粒度来控制一个事务中的语句。保存点允许我们有选择性地放弃事务的一部分而提交剩下的部分。在使用SAVEPOINT定义一个保存点后，我们可以在必要时利用ROLLBACK TO回滚到该保存点。该事务中位于保存点和回滚点之间的数据库修改都会被放弃，但是早于该保存点的修改则会被保存。在回滚到保存点之后，它的定义依然存在，因此我们可以多次回滚到它。反过来，如果确定不再需要回滚到特定的保存点，它可以被释放以便系统释放一些资源。记住不管是释放保存点还是回滚到保存点都会释放定义在该保存点之后的所有其他保存点。

创建一个数据库

PostgreSQL允许你在一个站点上创建任意数量的数据库。
数据库名必须是以字母开头并且小于 63 个字符长。
createdb 默认是创建用户名默认的db

kubernetes ingress 健康检测

https://ieevee.com/tech/2018/08/02/ingress-health.html

Node 最佳实践列表

https://github.com/goldbergyoni/nodebestpractices

推上看到的一个讲MySQL八股文的不错

MySQL 八股文应用篇 1

使用什么存储引擎比较多？有什么特点？
用不用索引？怎么用？
事务特性，详细讲一下？
ACID 中 I 有几种级别？
说一说使用的存储引擎使用哪种隔离级别？
如何检测慢查询？
EXPLAIN 怎么用？有什么关键字？
如何优化慢查询？

学习编程的最佳方式：learning by doing

Hotz 在多次直播的视频里提到编程不是看书就能学会的，learning by doing 才是最高效的学习方式。而且从他的视频里可以看出来，看书和 paper 不需要从头看到尾，甚至不需要看懂，先用起来再说。

Golang优秀库

UUID google出品基于RFC 4122和DCE 1.1的UUIDs的Go包。认证和安全服务。

可拓展的数据管理——数据管理是如何被打乱的

随着企业看到有了数据就有可能产生影响，数字化进程不断加快。数据使企业能够更好地了解客户，从而获得更好的、独特的个人体验。数据为企业提供了新的、差异化的机会，从而推动了销售的提升。有了数据，我们可以优化现有的流程，通过寻找模式来预测未来。它使得创新成为可能，我们可以开发新的收入模式。

随着人们对提高客户满意度、额外收入、新的商业模式和运营效率的高期望值，企业开始投资于数据仓库、大数据、商业智能和高级分析技术。这种架构的实施是一个很大的挑战，因为许多企业所面对的数据场景规模和复杂度都很大。通过组合系统来构建一个环境，这些系统都是单独设计和实施的，是一项耗时而复杂的工作。研究1显示，87%的组织在商业智能和分析方面的成熟度较低。

在这些成熟度的挑战旁边，我看到了一些大的趋势。本来就很复杂的数据格局，在外部和新的数据源的使用下，数据格局将继续增长。由于云计算、分离式和专用基础设施、软件即服务和API经济的推进，碎片化的趋势即将到来。同时也存在着对隐私、安全和监管部门日益关注的担忧。随着数据的黑暗面越来越清晰，政府的介入，数据管理成为重中之重。

管理、整合和分发数据场景将成为一个更大的问题，因为更快地进入市场的时间会更快。还有竞争的时间压力方面，需要更快地开发和交付业务案例。选择正确的模式是很困难的，在压力下，人们会走捷径，这将引入更多的复杂性，并将在更长远的角度上损害架构。

现有的挑战、复杂性和地平线上的新趋势是一种危险的鸡尾酒，这要求我们重新考虑如何进行数据管理和数据整合。为了在数字化的世界中生存，需要一个现代的数据架构，既能应对现有的挑战，又能照顾到未来的趋势和发展。

在这一章中，我将说明数据管理在组织中的重要性和变革的必要性，我将首先向大家展示一些影响行业内相当多变革的趋势。

首先，我将重点讨论外部驱动因素，即你的组织之外的影响我们的因素，如竞争对手、新技术或法规等。并非所有你读到的或被告知的东西都能成为实际的趋势，所以要能够区分真实的信息和那些被提供信息的人进行商业操纵的信息，这一点很重要。

然后，我将重点讨论内部驱动力，即来自组织内部的力量，如企业战略、结构、流程、技术能力或员工士气等。

Docker 修改时区

RUN apk add --no-cache tzdata
ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

关于Vue，为什么不用mixin这种来做数据处理呢？

通过这种方式，把数据层层UI层剥离层出来，UI层负责Html和一些HTML相关的数据绑定和事件，数据层就负责单纯的数据，或者一些通用数据逻辑，这样UI和数据的组合是否会更加灵活？

Java应用性能远程监控系统

https://github.com/onblog/JavaMonitor

适用于监控所有Java应用，具有堆内存监控、方法区监控、GC监控、类加载监控、类编译监控与线程监控，提供堆快照下载，线程快照下载。

Kafka

这张图显示了一个生产者进程附加到两个分区的日志中，和一个消费者从相同的日志中读取记录。日志中的每个记录都有一个相关的条目号，我们称之为偏移量。这个偏移量被消费者用来描述它在每个日志中的位置。

这些分区分布在一个机器集群中，允许一个主题容纳的数据比任何一台机器上都要多。

请注意，与大多数消息系统不同，日志始终是持久的。当接收到消息时，消息会立即写入文件系统。消息在读取时不会被删除，而是通过一些可配置的SLA（例如几天或一周）来保留。这允许在数据消费者可能需要重新加载数据的情况下使用。它还可以支持空间高效的发布-订阅，因为无论有多少个消费者，都有一个单一的共享日志；在传统的消息系统中，通常每个消费者都有一个队列，所以增加一个消费者会使你的数据大小增加一倍。这使得Kafka很适合做普通消息系统之外的事情，比如作为Hadoop等离线数据系统的管道。这些离线系统可能只是作为周期性ETL周期的一部分才会间隔加载，也可能会停机几个小时进行维护，在这段时间里，Kafka能够在需要时缓冲甚至是TB的未消耗数据。

Kafka还可以在多个服务器上复制其日志，以实现容错。与其他消息传递系统不同，我们的复制实现的一个重要架构方面是，复制不是一个需要复杂配置的异国情调，只在非常特殊的情况下使用。相反，复制被假定为默认情况：我们将未复制的数据作为一种特殊情况，当复制因子恰好为1时，我们将其作为一种特殊情况。

生产者在发布包含记录偏移量的消息时，会得到一个回执。发布到分区的第一个记录被赋予了偏移量0，第二个记录被赋予了1，以此类推，依次递增。消费者从一个偏移量指定的位置消耗数据，他们通过定期提交的方式将其位置保存在日志中：保存这个偏移量，以备该消费者实例崩溃时，另一个实例需要从它的位置恢复。

好了，希望这些都有意义（如果没有，你可以在这里阅读更完整的Kafka介绍）。

开源图书集

架构行动手册

别人家的元数据系统是怎么设计的

0x00 前言
本篇分享是元数据管理的内容，主要参考Google在2016年发布的论文《Goods: Organizing Google’s Datasets》以及 Linkedin 在2016年新开源的项目：WhereHows，当然也有笔者的一点理解。

Google 的论文整体描述十分详细，可以作为理论来学习，LinkedIn 已经开源了一个版本的系统，可以看成最佳实践。两者结合起来，还是很能拓展思路的。不太清楚 Google 和 Linkedin 真实的系统做成什么样，是不是像 Gfs 那样自己已经要淘汰了才发表文章出来。不过这个不重要。只要能学到一些新东西就行了。

本文没有具体的实现，只有各种的设计**。另外，其它数据仓库相关的文章请参考历史文章。

一、本文讲什么？
本文会围绕 Goods 来展开，辅助以 LinkedIn 的 WhereHows 和笔者的理解。

先整体说明一下 Goods 是什么？可以这样理解：

Google的数据表太多了，工程师们会生产出很多的数据表，为了更好地管理和复用这些表，Google做了一个数据管理系统

这个系统是一个开放的系统，它会通过类似爬虫的方式定时从各个系统（Hive、Hbase、Mysql）中抓取元数据信息然后存入系统中。并生产表之间的依赖关系。

他和 EDM 的不同在于，它是来爬各个系统的元数据，然后来汇总。这点很重要，属于一种事后处理。给了工程师更大的开放性。

二、文章结构
从我的感觉上来讲，元数据系统最经常被质疑的地方有两个：价值和作用。为了突出这两者的重要性，我会单独着重地写。

为什么：元数据系统的价值；

是什么：元数据系统相关的概念；

怎么做：分享一下Google的论文《Goods: Organizing Google’s Datasets》中的内容，只有部分内容；

怎么做：分享一下Linkedin的新开源的项目WhereHows的一些设计。

补充：自己的一些想法。

0x01 价值何在？
一、挑战
元数据的存在有它的必要性，我大致做了一个简单的梳理，列出一些和数据相关的挑战。这些其实也是元数据系统的价值所在。

二、数据问题
如果业务复杂度比较低或者数据量比较小的话，可能就感触不深，不过在Google这种公司来讲，表的数量之大，光是管理表的元数据系统就要做成分布式的。

看一下Google的数据量，是挺大的了。

三、使用问题
个人理解，这是元数据系统的主要战场。总的来讲，就是方便人使用。

特别是表的维护者、量级这些不太起眼的属性往往是十分重要的，这些额外信息的完善度直接决定别人在用这张表时候的可用性。

四、管理问题
举个栗子：假设你的集群已经快慢了，这时候要删除一些表来释放空间，但是你根本不知道哪些表有用，哪些没用？是不是很纠结？

元数据系统可以来管理这些。

包括不同员工的权限管理、数据质量监控这些功能，都可以通过元数据系统来体现。

0x02 背景知识和相关概念
大部分都加入了笔者个人理解，有误的请指出。

一、元数据
任何文件系统中的数据分为数据和元数据。

数据是指实际的数据，就是我们能看到的一条条记录。

而元数据指用来描述一个表的特征的系统数据，比如表的字段信息、访问权限、拥有者以及数据
块的分布信息(inode…)等等。

比如Hive就专门有自己的元数据，里面存了Hive每张表的表名、列信息、索引等信息。

二、元数据系统
管理元数据的系统。网上没找到定义，个人对它的理解如下：

一个管理元数据信息的系统

能够提供方便的元数据的操作和查询操作

三、EDM
EDM的方式是数据的发布和使用都要通过这个系统。

Enterprise Data Management (EDM) is one common way to organize datasets in an enterprise setting. However, in the case of EDM, stakeholders in the company must embrace this approach, using an EDM system to publish, retrieve, and integrate their datasets.

Goods的不同在于，它是事后处理的方式。

An alternative approach is to enable complete freedom within the enterprise to access and generate datasets and to solve the problem of finding the right data in a post-hoc manner. This approach is similar in spirit to the concept of data lakes , where the lake comprises and continuously accumulates all the datasets generated within the enterprise.

0x03 Google的设计
一、设计思路
Goods, a project to rethink how we organize structured datasets at scale, in a setting where teams use diverse and often idiosyncratic ways to produce the datasets and where there is no centralized system for storing and querying them.

看完论文之后整理了一份思维导图，整个 Goods 的设计思路如下，基本包含了论文中大部分的点。

二、整体架构
如下图，是 Goods 的整个设计架构。架构有几个点需要注意：

前面提到的多数据源，比如 Hbase、Hive 还有 Hdfs 路径这种也算。

数据设计。Google 抽象了一套数据模型，如图中展示了一部分

使用。就如图中列出来的一些。

注意：感觉论文的作者很自豪自己设计的血缘分析，论文中提了很多次。看下图的最右侧，为了获取到血缘图，他们做了不少的工作。

Overview of Google Dataset Search (Goods). The figure shows the Goods dataset catalog that collects metadata about datasets from various storage systems as well as other sources. We also infer metadata by processing additional sources such as logs and information about dataset owners and their projects, by analyzing content of the datasets, and by collecting input from the Goods users. We use the information in the catalog to build tools for search, monitoring, and visualizing flow of data.

三、数据模型
我一直感觉这个设计是最难的，因为要从那么多数据系统中抽象出来一份通用的数据模型。

数据模型整体分为两部分：基本的元数据信息和依赖关系。英文解释很清楚，就不再翻译了。

Basic metadata - The basic metadata for each dataset includes its timestamp, file format, owners, and access permissions. We obtain this basic metadata by crawling the storage systems and this process usually does not necessitate any inference. Other Goods modules often depend on this basic information to determine their behavior. For example, some of the modules bypass catalog entries that have restricted access or the entries that have not been modified recently.

provenance - Datasets are produced and consumed by code. This code may include analysis tools that are used to query datasets, serving infrastructures that provide access to datasets through APIs,
or ETL pipelines that transform it into other datasets. Often, we can understand a dataset better through these surrounding pieces of software that produce and use it.

0x03 Linkedin 的设计
Linkedin 的设计，就不再自己画思维导图了，主要从几个点来对 Google 的设计做一个补充，帮助更好的理解。

一、整体架构
WhereHows 从架构上来看主要分三个部分，和 Google 的 Goods 比较类似。

Data Model

Backend ETL

Web Service

二、数据模型
数据主要有四部分组成。图片有点不清楚，暂时没找到更清楚的。

Datasets: Dataset schema, comments, sample data…

Operational data: flow group, flow, job, job dependency, execution, id map tables (helper tables to generate unique IDs)

Lineage data: input and output of jobs, dependency, partition, high watermark

WhereHows ETL and Web UI/Service: configurations

三、血缘分析ETL
血缘分析的数据需要从如下方式来获取。

Lineage information refers to the dependency of jobs and datasets. It also includes some operation data, such as whether this is a read or write operation, and how many records it can read/write.

0x05 总结
一、总结
元数据系统属于数据仓库建设中的一部分，它的很多意义和价值其实是和数据仓库强绑定的。在最开始列举的一些元数据系统的挑战和数据仓库的挑战是重合的，不过这些也很能反应元数据系统的重要性。

关于 Google 和 LinkedIn 两家公司的设计，其实是很相近的，只是 Google 给出的是**，LinkedIn 给出的实现的，整体来看，两者的设计还是十分接近的，看一家的看不懂，看两家就行了。

二、个人补充
Google 和 LinkedIn 都比较关注提高开发者的开发体验，就是我再前面设计**里面列的无干扰。这样做的好处十分明显，就是不影响开发效率，侵入性很低。

个人感觉可以做一些补充，比如数据管理功能。

大部分互联网公司的童鞋都知道我们的数据源会有很多，因此都会有一个数据接入系统。我们可以把数据接入系统嵌到元数据系统中，开发一套自动化接入流程，用户如果想接入新的数据源了，可以通过元数据系统申请接入（离线或者实时）。

强烈建议把 Google 的论文和 LinkedIn 的开源项目看一下，会有很多收获的，比看数据仓库的经典书籍和网上的各种博客要靠谱很多很多。

Python 小技巧

https://github.com/brennerm/PyTricks

算法学习资源

参考资料

https://github.com/nanotrt/Introduction-to-Algorithms

总结：
基本上来源是这么几个地方，首先很多基础的东西主要来自四门课，CS61B by UCB,
CS106B by Stanford, Algorithm by Princeton, CSAPP by CMU.这些公开课都是精品中的精品，转专业的要打好基础尽量过一遍这些课程。
其他的主要是一些算法的应用和讲解。
主要推荐的有，
YouTube的WilliamFiest，这个人做的图片和动图很好，思路很清晰。
YouTube上印度博主Ravindrababu Ravula，用的白板，思路也很清晰。
B站up主正月点灯笼，这个up主很细致，而且会带你走一遍过程，写一遍代码。
B站up主大雪菜，讲得很清晰，而且每个题都会现场示范代码实现。
微信公众号 labuladong，讲了很多算法，总结得挺到位的。
力扣国服liweiwei1419，可能是目前最好的回溯算法讲解。

编程就是要动手

无侵入的java应用诊断工具

https://github.com/qunarcorp/bistoury

Bistoury

Bistoury 是去哪儿网开源的一个对应用透明，无侵入的java应用诊断工具，用于提升开发人员的诊断效率和能力。

Bistoury 的目标是一站式java应用诊断解决方案，让开发人员无需登录机器或修改系统，就可以从日志、内存、线程、类信息、调试、机器和系统属性等各个方面对应用进行诊断，提升开发人员诊断问题的效率和能力。

Bistoury 在公司内部原有agent的基础上集成Alibaba开源的arthas和唯品会开源的vjtools，提供了更加丰富的功能，感谢他们做出的优秀工作。

简介

Arthas和vjtools已经是很优秀的工具，我们为什么还要开发Bistoury？

Arthas和vjtools通过命令行或类似的方式使用，不可否认命令行在很多时候具有比较高的效率；但图形化界面也有其自身的优点，特别是在参数复杂时使用起来更加简单，效率更高。Bistoury在保留命令行界面的基础上，还对很多命令提供了图形化界面，方面用户使用。

Arthas和vjtools针对单台机器，从机器的维度对系统进行诊断，没有提供全局的视角；而在线应用往往部署在多台机器，Bistoury可以和使用方应用中心整合，从应用的维度对系统进行诊断，提供了更多的可能。

Arthas和vjtools在使用上，要么登录机器，要么需要使用者提供相应的ip和端口；Bistoury去掉各种设置，提供统一的web入口，从页面上选择应用和机器即可使用。

除了这些针对性优化，Bistoury在保留arthas和vjtools的所有功能之外，还提供了更加丰富的功能。

Bistoury的在线debug功能去掉了各种复杂参数，模拟ide调试体验，通过web界面提供断点调试的功能，可以在不阻塞应用的情况下捕获断点处的信息（包括本地变量、成员变量、静态变量和方法调用栈）。

Bistoury提供了线程级cpu使用率监控，可以监控系统每个线程的分钟级cpu使用率，并提供最近几天的历史数据查询。

Bistoury可以动态对方法添加监控，监控方法的调用次数、异常次数和执行时间，同时也保留最近几天的监控数据。

Bistoury提供了日志查看功能，可以使用tail、grep等命令对单台或同时对多台机器的日志进行查看。

Bistoury提供可视化页面实时查看机器和应用的各种信息，包括主机内存和磁盘使用、cpu使用率和load、系统配置文件、jar包信息，jvm信息、内存使用和gc等等。

快速上手

也许你正面对一个难以捉摸的线上问题束手无策，不妨来试试Bistoury的快捷部署脚本，在一分钟内启动Bistoury然后插入断点开始调试吧！

使用文档

java版本要求

ui、proxy使用Java1.8+，agent使用java1.7+，由于agent会attach到应用中，所以应用也需要使用Java1.7+，最好保持应用和agent的版本一致。点击这里使用Java11运行bistoury

系统要求

目前只支持linux系统（支持mac os）

project

欢迎大家各种star，fork，提issue，pull request，感觉还可以就点个star吧！

Q & A

前端有的地方似乎有点不那么好看，实现的似乎也不太棒

所有的前端代码都是后端同学兼职完成，欢迎各位前端大牛贡献相关代码。

常见问题汇总

使用Bistoury出现各种问题请先点这里

技术支持

qq群：717242486

Screenshots

通过命令行界面查看日志，使用arthas和vjtools的各项功能

在线debug，在线应用调试神器

线程级cpu监控，帮助你掌握线程级cpu使用率

在web界面查看JVM运行信息，以及各种其它信息

动态给方法添加监控

线程dump

文件下载

火焰图

java热点方法

psql 基本命令规则

\i命令从指定的文件中读取命令

工作和学习音乐

Focus with me

pg的一些高级特性

对视图的使用是成就一个好的SQL数据库设计的关键方面。视图允许用户通过始终如一的接口封装表的结构细节，这样可以避免表结构随着应用的进化而改变。

TCP 拥塞控制详解

https://mp.weixin.qq.com/s/KTKVu3uCC5MFlU5oylZPFA

索引使用策略及优化

创建索引

在经常查询而不经常增删改操作的字段加索引。
order by与group by后应直接使用字段，而且字段应该是索引字段。
一个表上的索引不应该超过6个。
索引字段的长度固定，且长度较短。
索引字段重复不能过多。
在过滤性高的字段上加索引。

使用索引注意事项

使用like关键字时，前置%会导致索引失效。
使用null值会被自动从索引中排除，索引一般不会建立在有空值的列上。
使用or关键字时，or左右字段如果存在一个没有索引，有索引字段也会失效。
使用!=操作符时，将放弃使用索引。因为范围不确定，使用索引效率不高，会被引擎自动改为全表扫描。
不要在索引字段进行运算。
在使用复合索引时，最左前缀原则，查询时必须使用索引的第一个字段，否则索引失效；并且应尽量让字段顺序与索引顺序一致。
避免隐式转换，定义的数据类型与传入的数据类型保持一致。

比尔盖茨的读书习惯

比尔·盖茨非常热爱阅读，并视其为探索事物和储备知识的最佳途径。他1年读50本书，也就是1周1本。在这个视频中，他给我们分享了他的几个阅读习惯和技巧——

0、集中注意力

1、在空白处做笔记：阅读时要集中精力，并确保在汲取新知识时与旧知识联系思考，在页面周围批注自己的想法。

2、不看你认为看不完的书：比尔·盖茨给自己立了个“看书就一定要看完”的规矩，所以他通常在书本的选择上有自己的要求。

3、纸质书>电子书：比尔·盖茨习惯阅读纸质书，即使外出旅游也会不嫌麻烦地背上个大书包。

4、每天腾出一小时阅读：读书不是用零零碎碎的时间拼凑而成的，而是需要专门抽出时间认真阅读。比尔·盖茨每晚都会花一个多小时的时间，来慢慢把书读完。

5、坚守自己的读书习惯和规矩，不要打破它

比尔·盖茨从小就爱阅读，是狂热的书迷。以上是他在长期的阅读中收获最大的阅读习惯和技巧，希望对你有借鉴之处。

Redis：我承载了上千万人的火影青春

https://cloud.tencent.com/developer/article/1692762?fromSource=gwzcw.1293314.1293314.1293314&cps_key=ad1dd5b36e1c498308f7302ab4cdabb7

Redis 八股文

Redis 八股文应用篇 1

Redis 有哪些数据结构，分别有什么使用场景？
Redis ZSET 相同 score 如何排序？
在爬虫中，如何使用 Redis 做 URL 去重？
Redis 是否支持事务？
Redis 中的 WATCH 命令是做什么的？
Redis 是如何保证高可用的？
如何使用 Redis 来实现分布式锁？Redlock？

CompletableFuture 在IO密集型应用中使用

https://headcrashing.wordpress.com/2015/07/20/iobound-completablefuture/

大家设计数据库时使用外键吗？ > > ```

CREATE TABLE cities (
        city     varchar(80) primary key,
        location point
);

CREATE TABLE weather (
        city      varchar(80) references cities(city),
        temp_lo   int,
        temp_hi   int,
        prcp      real,
        date      date
);
外键的行为可以很好地根据应用来调整。正确使用外键无疑会提高数据库应用的质量，因此强烈建议用户学会如何使用它们。

但是现在的主流应用都倾向于在应用层做处理，数据库层的使用较少

Originally posted by @ipkaq in #4 (comment)

可拓展数据管理—— 介绍分层架构：规模化组织数据

一个企业需要什么样的架构，才能成为数据驱动？如何在保持敏捷性、安全性和可控性的同时，高效分配数据？现在将解决这些问题，为数据管理奠定基础，并开始构建。

我们所看到的趋势要求我们重新思考数据管理和数据整合的方式。我们已经了解到了在对应用数据进行精确复制时出现的紧密耦合，以及分析的操作化的困难。我们也了解到了构建集成数据仓库的统一问题和巨大的努力，以及它对敏捷性的影响。我们需要做出的转变是，从将所有数据漏斗到一个单一的数据仓中，转向让域、团队和用户能够轻松、安全地分配、消费和使用数据。平台、流程和模式应该简化其他人的工作。我们需要简单、记录良好、快速和易于使用的界面。我们需要一个能在规模上发挥作用的数据管理架构。本章将讨论如何以不同的方式进行数据集成。

我所设想的分层架构侧重于数据管理和数据集成。它是一个针对企业的架构，旨在让团队能够安全、轻松地提供数据，同时保持敏捷性、控制力和洞察力。就像许多其他架构一样，它使用的是架构积木。这些积木将被反复使用，以帮助你认识到我们所讨论的架构的具体部分。

OpenGroup将架构积木定义为 "为满足业务需求而定义的功能包。将功能、产品和定制开发组装成积木的方式在各个架构之间会有很大的差异"。

让我们先来回顾一下，找出最实质性的构件。接下来我们将讨论一些补充文献，并得出一些结论。然后，最后，我们将讨论新的架构及其原理和它的剥离，看看里面有什么。到了最后，你就会明白这些不同的构件是如何工作的，并将其联系在一起。这些背景理论对于理解新架构的核心驱动力是必要的。在随后的章节中，我们将进一步深入到模式、详细设计、图表和工作流程，你将开始了解这个架构是如何将所有的数据管理领域联系在一起的

百亿级微信红包的高并发资金交易系统设计方案

https://www.infoq.cn/article/2017hongbao-weixin

从 0 开始解刨一个 App，以微信为例

https://github.com/lefex/iWeChat

MySQL 磁盘IO优化

磁盘寻址是一个巨大的性能瓶颈。当数据量开始增长到无法有效缓存时，这个问题就会变得更加明显。对于大型的数据库，你或多或少会随机访问数据，你可以肯定的是，你至少需要一次磁盘寻址来读取数据，同时需要几次磁盘寻道来写入数据。为了尽量减少这个问题，请使用低寻址时间的磁盘。

自动化 Kubernetes 最佳实践

https://codeburst.io/automating-kubernetes-best-practices-7a8276ff7b08

Nginx性能调优技巧

官方文章

小镇做题家

https://docs.google.com/spreadsheets/d/1QCulpk_RaXMfEhv2Ya-ccOa116ejT8NyN4CACulLXz0/edit#gid=1173162340

No.	#	Title
1	973	K Closest Points to Origin
2	238	Product of Array Except Self
3	560	Subarray Sum Equals K
4	273	Integer to English Words
5	124	Binary Tree Maximum Path Sum
6	269	Alien Dictionary
7	415	Add Strings
8	23	Merge k Sorted Lists
9	297	Serialize and Deserialize Binary Tree
10	199	Binary Tree Right Side View
11	211	Add and Search Word - Data structure design
12	426	Convert Binary Search Tree to Sorted Doubly Linked List
13	523	Continuous Subarray Sum
14	340	Longest Substring with At Most K Distinct Characters
15	543	Diameter of Binary Tree
16	636	Exclusive Time of Functions
17	76	Minimum Window Substring
18	139	Word Break
19	31	Next Permutation
20	349	Intersection of Two Arrays
21	215	Kth Largest Element in an Array
22	173	Binary Search Tree Iterator
23	721	Accounts Merge
24	33	Search in Rotated Sorted Array
25	767	Reorganize String
26	88	Merge Sorted Array
27	56	Merge Intervals
28	71	Simplify Path
29	270	Closest Binary Search Tree Value
30	29	Divide Two Integers
31	621	Task Scheduler
32	34	Find First and Last Position of Element in Sorted Array
33	785	Is Graph Bipartite?
34	938	Range Sum of BST
35	146	LRU Cache
36	286	Walls and Gates
37	140	Word Break II
38	98	Validate Binary Search Tree
39	133	Clone Graph
40	143	Reorder List
41	1004	Max Consecutive Ones III
42	236	Lowest Common Ancestor of a Binary Tree
43	528	Random Pick with Weight
44	314	Binary Tree Vertical Order Traversal
45	380	Insert Delete GetRandom O(1)
46	419	Battleships in a Board
47	42	Trapping Rain Water
48	463	Island Perimeter
49	863	All Nodes Distance K in Binary Tree
50	50	Pow(x, n)
51	138	Copy List with Random Pointer
52	200	Number of Islands
53	253	Meeting Rooms II
54	10	Regular Expression Matching
55	227	Basic Calculator II
56	162	Find Peak Element
57	277	Find the Celebrity
58	987	Vertical Order Traversal of a Binary Tree
59	529	Minesweeper
60	32	Longest Valid Parentheses
61	347	Top K Frequent Elements
62	490	The Maze
63	692	Top K Frequent Words
64	15	3Sum
65	114	Flatten Binary Tree to Linked List
66	515	Find Largest Value in Each Tree Row
67	348	Design Tic-Tac-Toe
68	1	Two Sum
69	323	Number of Connected Components in an Undirected Graph
70	977	Squares of a Sorted Array
71	239	Sliding Window Maximum
72	126	Word Ladder II
73	78	Subsets
74	3	Longest Substring Without Repeating Characters
75	540	Single Element in a Sorted Array
76	350	Intersection of Two Arrays II
77	257	Binary Tree Paths
78	207	Course Schedule
79	224	Basic Calculator
80	378	Kth Smallest Element in a Sorted Matrix
81	622	Design Circular Queue
82	20	Valid Parentheses
83	2	Add Two Numbers
84	468	Validate IP Address
85	39	Combination Sum
86	22	Generate Parentheses
87	79	Word Search
88	75	Sort Colors
89	230	Kth Smallest Element in a BST
90	332	Reconstruct Itinerary
91	105	Construct Binary Tree from Preorder and Inorder Traversal
92	121	Best Time to Buy and Sell Stock
93	417	Pacific Atlantic Water Flow
94	74	Search a 2D Matrix
95	394	Decode String
96	567	Permutation in String
97	5	Longest Palindromic Substring
98	127	Word Ladder
99	442	Find All Duplicates in an Array
100	57	Insert Interval
101	449	Serialize and Deserialize BST
102	662	Maximum Width of Binary Tree
103	266	Palindrome Permutation
104	969	Pancake Sorting
105	695	Max Area of Island
106	148	Sort List
107	4	Median of Two Sorted Arrays
108	160	Intersection of Two Linked Lists
109	772	Basic Calculator III
110	128	Longest Consecutive Sequence
111	698	Partition to K Equal Sum Subsets
112	19	Remove Nth Node From End of List
113	93	Restore IP Addresses
114	46	Permutations
115	8	String to Integer (atoi)
116	240	Search a 2D Matrix II
117	91	Decode Ways
118	516	Longest Palindromic Subsequence
119	329	Longest Increasing Path in a Matrix
120	210	Course Schedule II
121	102	Binary Tree Level Order Traversal
122	13	Roman to Integer
123	208	Implement Trie (Prefix Tree)
124	16	3Sum Closest
125	41	First Missing Positive
126	317	Shortest Distance from All Buildings
127	17	Letter Combinations of a Phone Number
128	212	Word Search II
129	54	Spiral Matrix
130	37	Sudoku Solver
131	295	Find Median from Data Stream
132	48	Rotate Image
133	62	Unique Paths
134	73	Set Matrix Zeroes
135	153	Find Minimum in Rotated Sorted Array
136	443	String Compression
137	44	Wildcard Matching
138	287	Find the Duplicate Number
139	129	Sum Root to Leaf Numbers
140	445	Add Two Numbers II
141	117	Populating Next Right Pointers in Each Node II
142	509	Fibonacci Number
143	11	Container With Most Water
144	21	Merge Two Sorted Lists
145	703	Kth Largest Element in a Stream
146	112	Path Sum
147	300	Longest Increasing Subsequence
148	437	Path Sum III
149	92	Reverse Linked List II
150	81	Search in Rotated Sorted Array II
151	242	Valid Anagram
152	70	Climbing Stairs
153	113	Path Sum II
154	53	Maximum Subarray
155	63	Unique Paths II
156	387	First Unique Character in a String
157	116	Populating Next Right Pointers in Each Node
158	151	Reverse Words in a String
159	235	Lowest Common Ancestor of a Binary Search Tree
160	118	Pascal's Triangle
161	152	Maximum Product Subarray
162	108	Convert Sorted Array to Binary Search Tree
163	206	Reverse Linked List
164	7	Reverse Integer
165	101	Symmetric Tree
166	283	Move Zeroes
167	136	Single Number
168	104	Maximum Depth of Binary Tree
169	344	Reverse String
170	49	Group Anagrams

监视网页性能指标的工具

https://github.com/keepfast/keepfast

SQL语言

--表示注释

文本分类：传统机器学习模型和深度学习模型

https://github.com/JepsonWong/Text_Classification

像架构师一样来思考微服务接口设计

如何做接口的设计

从我个人角度来说，可以从以下几个特性进行分析：

大规模系统和小规模系统
面向内部系统接口和面向外部系统的接口
大数据传输的接口和小数据传输的接口
长链接的接口和短链接的接口
很多时候我们优先考虑的是系统有多大，扩张性要有多好，对内还是对外以及我们有多大的能力。很多时候这个东西并没有一个定论，更多是基于业务和团队人员组成而决定的。

接口的实施

一定要做的事情

不管接口是对内的还是对外的，我们都要做以下几件事情：

接口功能定义是否明确，是否有功能重复的地方
接口的升级机制，是否能兼容以前的数据
接口的数据量是多少，是否需要使用传输压缩机制
接口的熔断点在何处，何时该降级或停止服务
接口的安全机制是怎么样的，如何将非法调用隔离开来
这些事情是我们在开始设计和实现接口的时候，必须要先想到的。但是不要认为我们想到了这些东西，我们就可以高枕无忧，然后事情就会像我们期待的那样发展下去。很多时候，接口都会变成像阿米巴原虫一样，不是圆的而是不规则的多边形。

对内的接口

对内的接口简单说就是 SOA，但是 SOA 也有很多种做法，例如常见的 dubbo 框架。在 dubbo 框架下，我们所做的事情完全可以说是在 dubbo 框架下进行业务开发，并定义 interface 然后暴露出去，我们此时貌似没有进行接口设计，但是实际上我们是完全按照 dubbo 的规范完成了接口的定义，没错就是那个 interface。看起来对内部的接口完全非常明确了，没什么可讲的，但是其中还是有很多东西可讲的，我先讲讲我们常见的。

对服务发现的方案选择：

使用主动推送的方式，注册中心每次发生变化都会推送最新的列表给服务的使用者
使用被动拉取的方式，注册中心每次变化都保存好，然后使用者每次调用服务者的时候，先到注册中心查询一次
好了，让我分别来说说这两个方案

使用主动推送

可以让使用者很快的更新服务者信息，使用者调用服务者的时候只需要在本地的一个 hash 表中查询一下即可，并且注册中心挂掉了之后，也不影响使用者调用服务者，看起来不错吧。那么让我来说说这方案的弊端，首先要实现 watch－notify 机制，大概有人会说不是有 Zookeeper 吗？自带该机制和数据冗余机制，那么我想说的是，当业务量起来的时候，Zookeeper 的 watch 机制真的能顶住吗？接着是，服务者的负载均衡并不好处理。那么有没有解决方法，这个可以参看 dubbo 中的注册中心是如何玩耍的。

使用被动拉取

这个好像很直观，但是每次都查询注册中心，这性能，注册中心能处理的了吗？大家不妨想一下 DNS 服务器，其实该方案完全可以使用简单的内部 DNS 实现。那么该方案的好处不言而喻，负载均衡好处理，并且非常简单。但是问题呢，性能和稳定性是要深入考虑的事情。

传输协议

剩下的就是需要考虑的传输协议了，为什么要考虑传输协议？原因很简单：

接口平均传输的数据量和自己的内网带宽的平衡
是否要跨语言协作
是否侵入业务了

为何考虑带宽

虽然注册中心第一步解决了我们的快速扩张的问题，但是呢，内网带宽毕竟是有限的。随着服务数量增多和调用量的增加，有时候我们会发现，同一个服务我们明明增加了 N 台部署响应时间却下降了很多，按照公式应该响应时间不变的呀？这个时候，我们可能猛然看到监控上我们的内网带宽已经跑满了。

为何考虑跨语言

难道一个公司不就是一种后端语言？其实不然，我曾见面试过一个公司，内部的业务之复杂，语言使用之繁多。很多时候，我们需要站在一个公司发展的角度上考虑这个问题，而不是一个纯技术的细节上考虑这个问题。

为什么要考虑是否侵入业务

不侵入业务，就是尽可能的封装底层的实现，让业务线更少的去考虑底层发生什么了。很多人说，这对业务线的人不公平，阻碍了他们的技术发展。其实不然，让业务线的同仁们更多，更深入的思考业务发展是非常重要的事情，我个人认为研发分两类，一类是玩算法和底层的，另一类就是深入业务的，他们都有自己的长处和短处。其实减少业务的侵入是为了更快的实现产品功能，让产品上线，让公司的业务快速迭代起来，这样对任何人都是有好处的。

接口升级

这个与其说是升级，不如说是怎么做不同版本的数据共存和 A/B 测试。一般在很多成行的 SOA 系统中，已经很完善了，我没必要在这里面多废话。但是还是要多说一句，数据多版本不易，且升且小心。

对外接口

对外接口，大家很快就会想到 Restful。随着现在创业的兴起，应当说是智能手机和 Web2.0 的兴起（更应该说的本质是，网络带宽变好，手机流量降价）。但是对外接口并不限于 Restful，还有大家不愿意谈的纯 Socket 接口。对外接口可讲的东西非常多，不过思路上基本上和对内接口没太大的差别，所以我这里就主要讲下为什么选择纯 Socket 的接口。

我们不愿意面对的长链接，很多研发，甚至公司级别，都不愿意去尝试这个技术。原因嘛，请看下面：

调试复杂，研发成本高
国内网络环境复杂，加重了第一条
国内用户对流量敏感，长链接心跳控制不好，容易被认为是偷流量
协议设计比较复杂，对研发的要求上升了很多
但是长链接真的就那么难嘛，其实不然。更多时候，是产品层面用不上，一般只有 IM 类型的应用或者实时对战类的游戏才会选择长链接。当然偶尔我们也想提供一些高互动的交互，如果只是在应用内短暂使用，完全可以选择 websocket（不过面对**强大的高铁和运营商基础建设的规划 TT）。

接口的保护

安全保护

当我们面对很多外部接口的时候，我们需要考虑数据的安全性。为什么要考虑安全性：

包含用户数据
包含交易数据
以及甚至你不想让用户自己知道的数据
保护接口的方式最基本的是 SSL/TLS，然后呢：

对称加密的方式
非对称加密的方式
动态秘钥
先说下我们为什么要在 SSL/TLS 下面再次进行加密呢？大家可能听说过以色列一个网络安全公司的事情了，换句话说一旦根证书被释放出去了，分分钟可以做 SSL/TLS 的 man in middle 的攻击。同时有些稍微高级的用户，会针对你的接口进行刷接口的行为。

对称加密

简单且易用。但是问题也明显，一旦秘钥泄漏或者被用户强猜出来了，那么影响还是很大的。

非对称加密的方式

实现略复杂，同样也面临第一种方式的问题。但是可以有一个专门的秘钥管理人员，生成公钥和秘钥对后，将公钥交付给客户端，将秘钥交付给服务器端，大大减少了泄漏的可能性。同时用户即便猜出了客户端的公钥，也无法解密别的用户提交的数据，而只能伪造请求。

动态秘钥

机器在运行的时候，定期自动和秘钥管控中心进行秘钥交换，每台机器在交互的时候使用的秘钥都不同。虽然可以带来一定的安全性，但是会给秘钥管理中心带来巨大的压力，同时调试也比较麻烦。这种方式个人认为适合使用在，传统小交易量的行业中，例如说银行的 ATM 机。

熔断保护

内部接口需要吗？

我们可以假定一个场景，服务者 A 有 10 个服务器，但是由于使用者 B 的算法错误，总是先选择服务者 A 的某台服务器，那么我们可以想象到服务者 A 的某台服务器压力非常大，然后逐步的就失去了响应，接着就会被认为被离线，接着使用者 B 又同样的方式打掉了第二台服务器。带来的影响就是，轻者响应速度很慢，严重的就是整个系统雪崩性的逐个崩溃停止服务。

一般怎么做

不管对内部还是对外部，我们都可以选择使用漏桶和令牌桶等算法来保护接口。对外部，我们还可以通过使用时间戳加整个 URL 整体签名技术来防止重放攻击和进行限流保护。