展豪说1-40d

展豪说（1-40d）

day1文章：《原来这才是kafka》
链接：https://www.jianshu.com/p/d3e963ff8b70
说明：对kafka架构讲解很清晰，对broker、topics、partitions、producer、consumer等概念讲解透彻。对比了kalfka和NMQ，

• 生产模式：kalfka是按Topic和Partition做batch写入，NMQ是直接写入。
• 消费模式：kalfka采用拉模式，NMQ采用推模式。
• 机器/节点状态：都是用zk做机器和节点信息管理，kalfka创建了controller模块做机器选主。
• 数据同步：kalfka的Topic是主从同步，可平行扩展；NMQ使用多层级联部署，层级之间cm-transfer做数据同步。
• 跨地域：kalfka跨地域支持不好，主从同步的耗时很高；NMQ级联部署支持跨地域，不影响本地耗时。
• 消息投递：kalfka有3种模式最多一次、最少一次和只且一次。NMQ是一次或无限重试，基本相近。
• 事务性：kalfka支持事务性操作和原子广播，NMQ不支持。

day2文章《<为什么你需要开源分布式流存储Pravega？》
链接: https://mp.weixin.qq.com/s?__biz=MzU1NDA4NjU2MA==&mid=2247494639&idx=2&sn=6f4891322f73df5dad349e2415b18031
说明: Pravega 设计宗旨是成为流的实时存储解决方案。具有以下特点:

• Pravega 的 Stream 是一个命名的、持久的、仅追加的、无限的字节序列
  • 使用低延迟追加尾写并从序列的尾读 (tail read/write)
  • 具有来自序列较旧部分的高吞吐追赶读 (catch-up read)
• 基于负载的自动 (zero-touch) 弹性伸缩特性 (scale up/scale down)
  • 许多写客户端同时追加写不相交的数据子集
  • 写入数据依靠路由键 (routing key) 写入不同的 segment 以保证隔离性
  • 让应用程序为写客户端分配键
  • 当键空间或写客户端发生改变时，对应的存储不能有约束和改变
  • 许多读客户端同时处理不相交的数据子集
  • 读取的数据分区不依赖于写入分区
  • 读取的分区由存储策略控制
  • 使用 segment 概念代替物理的分区，且数量根据摄取流量进行自动连续的更新

day3文章：《Redis 主从复制以及主从复制原理》
链接：https://mp.weixin.qq.com/s/1WpXw5zPQ_J2E8eFs44aWg
说明：Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
现在大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险。要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。

day4文章：《消息中间件如何实现每秒几十万的高并发写入》
链接：https://juejin.im/post/5c7bd09b6fb9a049ba424c15
说明：文章以kafka为例，简要的介绍了为什么消息中间件在消息需要落地磁盘的情况下能够实现高性能的读写，每秒几十万的并发，核心总结就是两点：

1. 页缓存+顺序磁盘写
2. 读取数据时使用零拷贝技术
   文章写的比较简单，不过对于了解一些通用的技术还是比较有帮助。

day5文章：
解密小米抢购系统千万高并发架构的演进和实践
链接：http://www.52im.net/thread-2323-1-1.html
说明：文章主要以小米手机抢购的场景来介绍如何做千万级高并发访问架构，讲解过程层层递进，有每一阶段的思考和总结，新阶段的思路等。秒杀的场景相对会单一一些，和春晚红包贴吧的场景还是不太一样，遇到的问题也不太一样，该文章也可以作为一种高并发场景案例，拓展下设计思路。

day6文章：《基于token的多平台身份认证架构设计》
链接：https://www.cnblogs.com/beer/p/6029861.html
说明：在存在账号体系的信息系统中，对身份的鉴定是非常重要的事情。
随着移动互联网时代到来，客户端的类型越来越多， 逐渐出现了 一个服务器，N个客户端的格局 。
不同的客户端产生了不同的用户使用场景，这些场景：

1. 有不同的环境安全威胁
2. 不同的会话生存周期
3. 不同的用户权限控制体系
4. 不同级别的接口调用方式
   综上所述，它们的身份认证方式也存在一定的区别。

day7文章：《开源Pravega架构解析：如何通过分层解决流存储的三大挑战？》
链接：https://mp.weixin.qq.com/s/8daT9tBHyhXaOcijve_XVA
说明：剖析当前流行的大数据存储存在的问题，从 Pravega 的架构角度出发，挖掘流存储的具体需求，重点介绍了 Pravega 的关键架构以及关键特性，并且通过架构的设计解决这些问题，实现：降低开发成本、减少存储成本与减少运维成本。另外还与 Kafka 做了简要对比。

day8文章：《记一次Elasticsearch优化总结》
链接：https://juejin.im/post/5bab49d75188255c2f42218b
说明：对于ES出现请求超时的问题阴险，从JVM原理的角度分析了问题出现的原因，并通过调节JVM参数验证了其对于ES性能的影响。主要内容如下：

1. 堆内存。堆区分为新生代和老年代，新生代又分为Eden区，from survivor区，to survivor区。
2. 堆内存分配。

• 大部分对象创建时，在eden区分配；
• 大的对象直接进入老年代，比如很长的字符串或数组。这些对象对垃圾回收不友好。
• 长期存活的对象，将从新生代晋升到老年代。

1. 堆回收策略

• 标记-清除算法
• 复制算法
• 标记-整理算法
• 分代收集算法

1. JVM新生代和老年代比例设置经验

• 新生代太小：导致minior gc回收频繁，可适当加大新生代大小
• 老年代太大：导致major gc或full gc回收时间过长，可适当减少老年代大小
• 如何确定新生代、老年代大小？
  • 总大小：3-4倍活跃数据大小
  • 新生代：1-1.5倍活跃数据大小
  • 老年代：总大小-新生代

day9文章：《如何处理redis集群中big key和hot key》
链接：https://www.jianshu.com/p/58615a1e2cac
说明：简单介绍了redis分片计算方式以及hot key出现的原因，如何对hot key和big key进行优化，以及提前发现、监控、自动处理来进行优化解决，对于解决目前遇到的问题有一定的启发作用。
1、hot key优化：利用分片算法的特性，对key进行打散处理
通过给hot key增加前缀或后缀，把一个hotkey 的数量变成 redis 实例个数N的倍数M，从而由访问一个 redis key 变成访问 N * M 个redis key
2、如何发现 hot key，big key
1）事前-预判
2）事中-监控和自动处理

day10文章：《关于Redis的一些思考和总结》
链接：https://www.jianshu.com/p/b8880db58241
说明：介绍了作者在使用redis过程中的一些经验、疑惑、思考进行归纳和总结，主要是以下几个方面
1、Redis的线程结构，单线程结构、异步化组件、最佳线程数、性能瓶颈、阻塞场景
2、过期和淘汰策略，令人困惑的expire、单线程中的定时器、淘汰策略和时机
3、数据结构的选择，内部数据结构实现、hash/B+/LSM的特点和场景对比
4、高可用和集群部署的方式

day11工具：GoReplay
链接：https://github.com/buger/goreplay
说明：GoReplay是一个开源工具，用于将实时HTTP流量捕获和重放到测试环境中，以便使用真实数据连续测试系统。核心功能包括：限速、放大流量、请求过滤和重写，还可以使用中间件实现定制逻辑。

day12文章：SlimTrie：战胜Btree单机百亿文件的极致索引
链接：http://www.zhuanzhi.ai/document/a5bf7d1bc219b44e706baf52eacaa6ca
说明：海量数据为存储系统增加了大量的小文件，这些小文件的元数据如何管理？如何控制定位某个文件的时间和空间开销？作者在涉及整体上对元数据管理采用无中心的设计，索引采用分层的思想，抛弃中心化元数据管理的策略, 将元数据分散到每个单机存储服务器;单机上, 部署了一套全新的索引数据结构: SlimTrie。对索引数据进行了裁剪、压缩和聚合的方法，对索引进行了极大的优化, 逼近空间利用率的理论极限。文章前作还有设计篇，可以参考思路。

day13文章：
HTTP和HTTPS详解
链接：https://blog.csdn.net/mingli198611/article/details/8055261
说明：HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTPS（Hypertext Transfer Protocol over Secure Socket Layer，基于SSL的HTTP协议）使用了HTTP协议，但HTTPS使用不同于HTTP协议的默认端口及一个加密、身份验证层（HTTP与TCP之间）。这个协议的最初研发由网景公司进行，提供了身份验证与加密通信方法，现在它被广泛用于互联网上安全敏感的通信。

day14文章：GDP / Golang微框架Gin
链接：http://gdp.baidu-int.com/ https://juejin.im/entry/5b8e7dd96fb9a019fe686623
说明：这些天正在用GDP进行业务的开发，而GDP底层正是用的是Gin框架，通过本文的介绍，快速上手Gin框架，为GDP最佳实践提供指导。Gin是一个轻巧而强大的golang web框架。涉及常见开发的功能，我们都做了简单的介绍。关于服务的启动，请求参数的处理和响应格式的渲染，以及针对上传和中间件鉴权做了例子。

day15文章：golang学习连载
链接：http://morsmachine.dk/go-scheduler
https://www.jianshu.com/p/47691d870756
http://legendtkl.com/2017/04/28/golang-gc/
https://www.jianshu.com/p/24ede9e90490
说明：介绍了golang核心组件设计，包括goroutine调度、内存分配和回收、channel的原理。整理为下图：

day16文章: 最终一致性分布式事务如何保障生产中99.99%高可用
链接: https://juejin.im/post/5bf2c6b6e51d456693549af4
说明: 对于常见的微服务系统, 大部分接口调用是同步的, 也就是一个服务直接调用另外一个服务的接口, 此时用TCC分布式事务来保证各个接口的调用.
但在实际系统的开发过程中, 可能服务间的调用是异步的. 即一个服务发送消息给MQ, 另一服务从MQ消费到一条消息后处理.
针对这种基于MQ的异步调用, 如何保证各个服务间的分布式事务呢?
这个时候, 就要用上可靠消息最终一致性方案, 来实现分布式事务.

day17文章:
App开放接口api安全性—Token签名sign的设计与实现
链接: https://www.cnblogs.com/whcghost/p/5657594.html
说明: 在app开放接口api的设计中，避免不了的就是安全性问题，因为大多数接口涉及到用户的个人信息以及一些敏感的数据，所以对这些 接口需要进行身份的认证，那么这就需要用户提供一些信息，比如用户名密码等，但是为了安全起见让用户暴露的明文密码次数越少越好，我们一般在web项目 中，大多数采用保存的session中，然后在存一份到cookie中，来保持用户的回话有效性。但是在app提供的开放接口中，后端服务器在用户登录后 如何去验证和维护用户的登陆有效性呢，以下是参考项目中设计的解决方案，其原理和大多数开放接口安全验证一样，如淘宝的开放接口token验证，微信开发 平台token验证都是同理。

day18文章：
写入消息中间件的数据，如何保证不丢失
链接：https://juejin.im/post/5c7e7a046fb9a04a07311fe7
说明：继上一篇文章介绍了消息中间件kafka如何实现高性能的写入后，介绍了在大数据量下，怎么保障写入kafka的数据能够在高效写入的情况下保持不丢失，介绍了kafka中的topic、partition和ISR表的的概念。ISR机制简单来说，就是会自动给每个Partition维护一个ISR列表，这个列表里一定会有Leader，然后还会包含跟Leader保持同步的Follower。也就是说，只要Leader的某个Follower一直跟他保持数据同步，那么就会存在于ISR列表里，要满足写入不会丢失，则：

• 每个Partition都至少得有1个Follower在ISR列表里，跟上了Leader的数据同步
• 每次写入数据的时候，都要求至少写入Partition Leader成功，同时还有至少一个ISR里的Follower也写入成功，才算这个写入是成功了
• 如果不满足上述两个条件，那就一直写入失败，让生产系统不停的尝试重试，直到满足上述两个条件，然后才能认为写入成功

day19文章：Spark几个基本概念、Spark Web UI
链接：https://blog.csdn.net/jiangwlee/article/details/50774561（基本概念）
https://blog.csdn.net/u013013024/article/details/73498508（spark web ui）
https://blog.csdn.net/qq_27639777/article/details/81069893 (spark web ui)
说明：Driver Program, Job、Stage和Task这些是Spark中的基本概念，而初学者对这些感念难以立刻消化理解，自己也是绕了些弯路。上面的基本概念文章，通过举例、示意图的方式，很好的解释了这些个概念。Spark Web UI能看到我们作业执行的统计信息以及相应的日志，是调试优化Spark任务的主要入口。通过Spark Web UI 结合上面的基本概念，更好的去理解spark。

day20文章: Nginx 多进程高并发、低时延、高可靠机制在滴滴缓存代理中的应用
链接：https://www.tuicool.com/articles/raaU7nm
说明：twemproxy为单进程单线程模型，无法利用多核特性。本文介绍了如何把nginx的高性能、高可靠、高并发机制引入到twemproxy中，通过master+多worker进程来实现七层转发功能。主要内容如下:

• Master-worker多进程机制原理
• 如何解决“惊群”问题
• 如何解决“负载均衡“问题
• Linux内核高版本TCP REUSEPORT特性如何利用
• Master进程和worker进程如何通信？
• 如何减少worker进程在不同cpu切换的开销
• worker进程异常如何减少对业务的影响？

day21文章：为什么开发人员必须要了解数据库锁？
链接： https://my.oschina.net/u/4072299/blog/3021230
说明：
对比项
InnoDB
MyIsAM
事务
支持
不支持
锁
支持MVCC行锁
表锁
外键
支持
不支持
存储空间
存储空间由于需要高速缓存，较大
可压缩
适用场景
有一定量的update和Insert
大量的select

day22文章：go 实现函数异步执行顺序返回值
链接：https://studygolang.com/articles/18854
说明：在go中利用chan嵌套chan的方式实现异步调用顺序返回功能。

day23文章: 单体到微服务是一个演化过程, 别在一开始就过度设计
链接: https://www.infoq.cn/article/t8yg7TLUSK19sFAG_YV3
说明: 大多数应用程序采用了单体架构。为了避免过度工程化，我们应该从一个简单的架构开始，并根据需求进行演变.
从某种形式的单体架构开始，最后得到一组微服务，这是大公司的常见演变模式。这种模式包含了两个部分——没有人从一开始就采用微服务架构，而是达到一定规模后才走向微服务.
大多数应用程序采用单体架构就足够了，在构建新应用程序或系统时先从简单的架构开始，并根据需要改进架构.

day24文章：B+树：MySQL数据库索引是如何实现的？
链接：http://note.youdao.com/noteshare?id=bb8a31b9b494c1e72d84d936107779c3 （来源：极客时间）
说明：介绍了数据库索引底层实现的数据结构和算法：依次从散列表->平衡二叉查找树->跳表进行分析判断，然后通过改造二叉查找树来解决这个问题，最后对B+树索引处理思路进行了详细的讲解。

day25文章：安全-HTTPS降级攻击
链接：https://blog.csdn.net/weixin_34293902/article/details/88318692
说明：介绍了https协议及什么是https协议降级

day26文章: Service Mesh 及其主流开源实现解析
链接：https://mp.weixin.qq.com/s/ANoLMEqCPkj9rhWKCmcT7Q
说明：Service Mesh 直译过来是服务网格，目的是解决系统架构微服务化后的服务间通信和治理问题。
Service Mesh

day27文章：美团点评分布式ID生成系统
链接：https://tech.meituan.com/2017/04/21/mt-leaf.html
说明：使用了snowflake id分配方案 + Leaf-segment存储方案 +支持step + 双buffer优化 + +高可用容灾(zk) + 避免时钟回逆 技术手段建立了分布式ID生成系统。按时间序列递增，（1L<<41）/(1000L360024*365)=69年，同一个毫秒下在不同Leaf节点上请求的id可能出现乱序，概率很低，因此该系统生成出的Id不是严格递增而是趋势递增的，同时可以避免暴露id，对标贴吧id分配器clubcm还是复杂很多的。

day28文章：
万字解读:Service Mesh服务网格新生代–Istio
链接：https://zhuanlan.zhihu.com/p/29586032
说明：微服务，服务网格，lstio，近年来大热的方向，发展实在是太快了，目前国内微服务还没有完全落地，服务网格也只是部分公司在推进，关于lstio的资料就更少了，文章介绍了微服务，服务网格，lstio之间的关系。重点介绍了lstio能做什么以及lstio的价值，总结起来就是Istio 能大幅降低微服务架构下应用程序的开发难度，势必极大的推动微服务的普及。

day29文章：
深入理解PHP单例模式的实现&static&clone
链接：https://blog.csdn.net/qq_34694342/article/details/81298988
说明：
提到单例模式，那就不得不说设计模式。
单例模式是最简单的一种设计模式，提供了一种唯一访问其对象的方式，可以直接访问。
属于创建型模式
实现之前，我们先要明白两个关键字的原理

day30文章：未来架构| 云原生时代的分布式事务
链接：https://mp.weixin.qq.com/s/17pTQM7ETYtLlB9dcI246w
说明：关系型数据库虽然对本地事务提供了完美的ACID原生支持。但在分布式的场景下，它却成为了系统性能的瓶颈。在ACID事务中，对隔离性的要求很高，在事务执行的过程中必须将所有的资源锁定。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面移至业务层面，通过放宽对强一致性的要求来换取系统吞吐量的提升。本文介绍了如下分布式事务：

• XA协议：使用两阶段提交来保证分布式事务的原子性以，它将提交过程分为准备阶段和提交/回滚阶段。
• 柔性事务：基于BASE事务要素的事务则称为柔性事务。实现柔性事务的方案主要有最大努力送达、Saga 、TCC和消息驱动

day31文章：百度 App 网络深度优化系列（一）：DNS 优化
链接：https://www.infoq.cn/article/3QZ0o9Nmv*O0LoEPVRkN
说明：网络优化是客户端几大技术方向中公认的一个深度领域，所以百度 App 带来了网络深度优化系列文章，其中包含系列《一》DNS 优化，系列《二》连接优化，系列《三》弱网优化，希望对大家在网络方向的学习和实践有所帮助。

day32文章：搜索的原理，架构，实现，实践
链接：https://mp.weixin.qq.com/s/5pSww9EyI8GMtsttmC08ow
说明：我们虽然不做搜索引擎，但大多数同学都遇到要实现检索的需求。本文给大家一些搜索、检索所包含的技术一些启示

day33文章：如何设计一个百万级的消息推送系统
链接：https://mp.weixin.qq.com/s?__biz=MzU0OTk3ODQ3Ng==&mid=2247484763&idx=1&sn=955cbb84415945d9daed54675f143d67&chksm=fba6ed58ccd1644ed588bc52874ee6799b0eb3b2c50c3d5e97a24f9041e0bef4d0f3cd6baa0d&mpshare=1&scene=1&srcid=0329hv0yeQqPSj8maAst9NI9&key=777fbaac34b7f3b671191535ab86b6f42b20327ff948ff8e64a367b0ebc19e3f5b8a7d33bef18202bce5f8a552bdfbe792994457aa4f5cdf4624972d8afb8a9e93f09d72e959943d03bc6d39cf0936ac&ascene=0&uin=NjM1MDYyODIw&devicetype=iMac+MacBookPro12%2C1+OSX+OSX+10.12.6+build(16G1710)&version=12020110&nettype=WIFI&lang=zh_CN&fontScale=100&pass_ticket=m4cm4ScM3zceJF12YWnvaCA0oEF%2Bq88QgJaSmsrTNozfxzyYgxVyLdxkPVwDBBMe
说明：该文章则通过长连接建立和维系，路由规则制定，负载均衡选择，协议解析等角度详细介绍了分布式在线推送服务如何搭建，可以参考借鉴下

day34文章： SaaS的12要素
链接：https://12factor.net/zh_cn/
如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论：

• 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
• 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
• 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
• 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
• 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。
  这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。

day35文章: 新版本 Golang 包管理
链接: https://juejin.im/post/5c9c8c4fe51d450bc9547ba1
说明: 新版本的包管理模式解决了一下问题

1. 自动下载依赖包
2. 项目不必放在GOPATH/src内了
3. 项目内会生成一个go.mod文件，列出包依赖
4. 所以来的第三方包会准确的指定版本号
5. 对于已经转移的包，可以用replace 申明替换，不需要改代码

day36文章：为什么超长列表数据的翻页技术实现复杂
链接：https://timyang.net/data/key-list-pagination/
说明：分析了用数据库存储超长列表的实现方法，以及优化方法。

day37文章：一篇文章看懂事务的一致性
链接：https://my.oschina.net/u/1778239/blog/3027565
摘要：事务的一致性和线程安全所面对的问题一模一样，要想维持一致性，需要保证两点：共享变量的可见性、临界区代码访问的顺序性。

day38文章：全链路监控（一）：方案概述与比较
链接：https://juejin.im/post/5a7a9e0af265da4e914b46f1
说明：全链路监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，
可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间

day39文章：基于 Kafka 实现分布式事件驱动
链接：https://www.infoq.cn/article/6*X2OJwYGdzuWJiaVqiz
说明：介绍了基于 Kafka 搭建事件驱动系统的方案，对于后续处置中心相关的升级可以参考

day40文章：面对日近两百亿数据量，美图大数据平台如何建成？
链接：https://www.toutiao.com/i6594599821221298691/
说明：论述了美图大数据平台的演变过程，并对其中遇到的一些问题提出了解决方案，对于贴吧大数据平台的建设具有指导意义。