在找工作的过程中，对于 Redis 技术知识的掌握已经成为必须的技能。本 Chat 针对 Redis 大部分知识点梳理出来常见的面试题目，提供给大家进行有针对性的学习。 本 chat 详细覆盖了： 1. Redis 的概念理解 2. Redis 基本数据结构详解 3. Redis 高并发问题策略 4. Redis 集群结构以及设计理念 5. Redis 持久化机制 6. Redis 应用场景设计 部分涉及到的题目如下： - 什么是 Redis? - Redis 的特点有哪些？ - Redis 支持的数据类型 - 为什么 Redis 需要把所有数据放到内存中？ - Redis 适用场景有哪些？ - Redis常用的业务场景有哪些？ - Memcache 与 Redis 的区别都有哪些？ - Redis 相比 memcached 有哪些优势？ - Redis常用的命令有哪些？ - Redis 是单线程的吗？ - Redis 为什么设计成单线程的？ - 一个字符串类型的值能存储最大容量是多少？ - Redis各个数据类型最大存储量分别是多少? - Redis 持久化机制有哪些？ 区别是什么？ - 请介绍一下 RDB, AOF两种持久化机制的优缺点？ - 什么是缓存穿透？怎么解决？ - 什么是缓存雪崩？ 怎么解决？ - Redis支持的额Java客户端有哪些？ 简单说明一下特点。 - 缓存的更新策略有几种？分别有什么注意事项？ - 什么是分布式锁？有什么作用？ - 分布式锁可以通过什么来实现？ - 介绍一下分布式锁实现需要注意的事项？ - Redis怎么实现分布式锁？ - 常见的淘汰算法有哪些？ - Redis 淘汰策略有哪些？ - Redis 缓存失效策略有哪些？ - Redis 的持久化机制有几种方式？ - 请介绍一下持久化机制 RDB, AOF的优缺点分别是什么？ - Redis 通讯协议是什么？有什么特点？ - 请介绍一下 Redis 的数据类型 SortedSet(zset) 以及底层实现机制？ - Redis 集群最大节点个数是多少？ - Redis 集群的主从复制模型是怎样的？ - Redis 如何做内存优化？ - Redis 事务相关命令有哪些？ - 什么是 Redis 事务？原理是什么？ - Redis 事务的注意点有哪些？ - Redis 为什么不支持回滚？ - 请介绍一下 Redis 集群实现方案 - 请介绍一下 Redis 常见的业务使用场景？ - Redis 集群会有写操作丢失吗？为什么？ - 请介绍一下 Redis 的 Pipeline (管道)，以及使用场景 - 请说明一下 Redis 的批量命令与 Pipeline 有什么不同？ - Redis 慢查询是什么？通过什么配置？ - Redis 的慢查询修复经验有哪些？ 怎么修复的？ - 请介绍一下 Redis 的发布订阅功能 - 请介绍几个可能导致 Redis 阻塞的原因 - 怎么去发现 Redis 阻塞异常情况？ - 如何发现大对象 - Redis 的内存消耗分类有哪些？内存统计使用什么命令？ - 简单介绍一下 Redis 的内存管理方式有哪些？ - 如何设置 Redis 的内存上限？有什么作用？ - 什么是 bigkey？ 有什么影响？ - 怎么发现bigkey? - 请简单描述一下 Jedis 的基本使用方法？ - Jedis连接池链接方法有什么优点？ - 冷热数据表示什么意思？ - 缓存命中率表示什么？ - 怎么提高缓存命中率？ - 如何优化 Redis 服务的性能？ - 如何实现本地缓存？请描述一下你知道的方式 - 请介绍一下 Spring 注解缓存 - 如果 AOF 文件的数据出现异常， Redis服务怎么处理？ - Redis 的主从复制模式有什么优缺点? - Redis sentinel (哨兵) 模式优缺点有哪些？ - Redis 集群架构模式有哪几种？ - 如何设置 Redis 的最大连接数？查看Redis的最大连接数？查看Redis的当前连接数？ - Redis 的链表数据结构的特征有哪些？ - 请介绍一下 Redis 的 String 类型底层实现？ - Redis 的 String 类型使用 SSD 方式实现的好处？ - 设计一下在交易网站首页展示当天最热门售卖商品的前五十名商品列表? 等等...... 通过本 Chat 详细大家能够轻松的应对 Redis 相关的面试挑战，同时也可通过全面的面试题目来学习和巩固自己的知识。

MongoDB 是非关系型数据库（NoSQL）的代表之一，它具有高灵活、可水平扩展、高可用等优秀特性，并且它提供了强大又丰富的查询语句使开发者能够随心所欲地操控数据。这些也正是它受到广大开发者和企业青睐的原因。 在本场 Chat 中，会讲到如下内容： - 流式聚合操作的概念 - MongoDB 中的管道 - 常用的管道指令 - Map-Reduce - 简单的聚合操作 - finallize 剪枝 适合人群： 对 MongoDB 感兴趣的开发者

GoMonkey 是作者为 Go 语言开发的一款打桩框架，目标是让用户在单元测试中低成本的完成打桩，从而将精力聚焦于业务功能的开发。GoMonkey 接口友好，功能强大，目前已被很多项目使用，用户遍及世界多个国家。 GoMonkey 的特性列表： - 支持为一个函数打一个桩 - 支持为一个成员方法打一个桩 - 支持为一个全局变量打一个桩 - 支持为一个函数变量打一个桩 - 支持为一个接口打一个桩 - 支持为一个函数打一个特定的桩序列 - 支持为一个成员方法打一个特定的桩序列 - 支持为一个函数变量打一个特定的桩序列 - 支持为一个接口打一个特定的桩序列 GoMonkey 初步计划了 2 个大版本： - GoMonkey1.0 提供丰富的命令式 API，可以满足用户各种场景的基本打桩诉求 - GoMonkey2.0 提供强大的 DSL，增强打桩功能，同时提升易用性 GoMonkey1.0 在 Github 发布一年后，已获得 200 多个 star，同时即将启动 GoMonkey2.0 的开发。在这个承上启下的阶段，作者想写一篇 Chat 来系统梳理 GoMonkey1.0 框架设计与应用实践。 本 Chat 的主要内容包括： - GoMonkey 介绍 - GoMonkey 是什么 - GoMonkey 与其他打桩框架的比较 - GoMonkey 与 GoMock 的比较 - GoMonkey 与 GoStub 的比较 - GoMonkey 与 Monkey 的比较 - 框架设计 - API 设计 - 领域模型 - 跨平台 - 注意事项 - 应用实践 - 为一个函数打一个桩 - 为一个成员方法打一个桩 - 为一个全局变量打一个桩 - 为一个函数变量打一个桩 - 为一个接口打一个桩 - 为一个函数打一个特定的桩序列 - 为一个成员方法打一个特定的桩序列 - 为一个函数变量打一个特定的桩序列 - 为一个接口打一个特定的桩序列

《浮现式设计》作者对于浮现式设计的定义：不断响应需求变化而系统不断演化的过程。其目标是为了提升效率并使风险最小化。Neal Ford 提出演进式架构的设计本身就是支持由于新业务不断出现所带来的演进式问题，是建立在持续集成、持续交付、DevOps、基础设施即代码的基础之上的，与原来的适应性架构的技术趋势生态已有很大不同。 我们经常提到一句话“架构不是设计出来的，而是演进出来的”。这话是非常有道理的，第一版上线的淘宝程序还是买软件然后修改的，肯定无法预料 3 年后业务发展的方向。但架构也是需要被设计的，结合当下和未来可见业务规模、业务发展趋势对核心架构做对应的预设。笔者尝试从如何识别增加演进架构和“代际架构”角度，以及如何做演进角度说一下自己的理解。

2019 年，全世界的开发人员都开始习惯用容器来测试自己的软件，用容器做线上发布，开始对容器化的软件构建和交付流程习以为常。在“云”已经成为了大众基础设施的今天，我们已经习惯了把“容器“当做现代软件基础设施的基本依赖。 时至今日，容器镜像已经成为了现代软件交付与分发的事实标准。我们知道，Kubernetes 是一个“重 API 层” 的项目，但我们还应该理解的是，Kubernetes 是一个“以 API 为中心”的项目。围绕着这套声明式 API，Kubernetes 的容器设计模式，控制器模型，以及异常。 ----- 讲师：**张磊，** 阿里巴巴高级技术专家 CNCF 官方大使（Ambassador)，Kubernetes 项目资深成员和联合维护者，目前在阿里云容器平台团队。 <font color=#008000>**限时福利：张磊、李响等人撰写的 [《CNCF X 阿里巴巴云原生技术公开课》](https://gitbook.cn/m/mazi/comp/column?columnId=5d68b823de93ed72d6eca1bc&utm_source=chat0909) 限时 0 元领取中。**</font>

3 年前，作者在简书上写了一篇文章[《轻松 TDD 之旅》](https://www.jianshu.com/p/41b48a771a35)，当时获得了很多同学的认可。今天，回头看这边文章，却发现有很多地方值得改进。趁这次 `GitChat 有奖征文：我的技术实践`，作者决定将这几年 TDD 的一些心得和感悟也反映到文章的结构和要点中去，使得 TDD 之旅在 2.0 版本更深刻，更完备，更流畅。 本 Chat 的主要内容为： - TDD 简介 - TDD 是什么 - TDD 的过程 - 关键点 - TDD进阶 - 六字真言：红色，绿色，蓝色 - 六子真言介绍：重点阐述什么是蓝色 - 如何变色：重点是小步安全流畅的从绿色变成蓝色 - 如何取舍：确定一个清晰的标尺 - to do list 拆分 - 自顶向下：实例化 - 自底向上：实例化 - TDD 实战 本文已参加 GitChat「我的技术实践」有奖征文活动，活动链接：[ GitChat「我的技术实践」有奖征文活动](https://gitbook.cn/gitchat/activity/5d5e3d9d877aaf2c49e5c87e)

本文是作者结合 2019 年 07 月 12 日在 ArchSummit 全球架构师峰会 DDD（领域驱动设计）落地探索专场做的主题分享：《DDD 战略建模在重构业务系统中的实践》的内容整理而成。 我是来自罗辑思维得到 app 的韩宇斌，很荣幸能有机会和大家分享我的一些心得，我分享的主题是《DDD 战略建模在重构业务系统时的实践》，内容分为三部分：第一部分是：用领域驱动来把握真正的业务需求；第二部分：领域驱动设计指导架构设计与建模；第三部分：用限界上下文来保护领域。 如果把我的分享比作一个故事的话，那么故事的主线是：领域驱动设计帮助我解决了工作的难题。这个难题表现在两个方面，首先无路可退 ：入职第一个任务，做不成就意味着回家。其次是左右为难 ：实现技术重构的目标，满足不了业务需求！不去实现，又不知道该做什么？ …… 本文已参加 GitChat「我的技术实践」有奖征文活动，活动链接：[ GitChat「我的技术实践」有奖征文活动](https://gitbook.cn/gitchat/activity/5d5e3d9d877aaf2c49e5c87e)

《当 DDD 遇上 DCI》是笔者在全球架构师峰会 2019 深圳站分享的一个话题，受到了很多学员的认可和肯定。为了将该话题的核心知识点和实践经验传播给更多有意愿提升自己 DDD 建模能力的同学，笔者决定写一篇 Chat 来详细阐述。 DDD 是一种主流的软件设计和开发的方法，DCI 是一种软件架构模式，当 DDD 遇上 DCI 会发生什么样的故事呢？我们将结合典型案例一起探讨，共同成长，从而有效降低开发成本。 本场 Chat 的主要内容为： 1. 深入浅出 DCI 架构模式 2. 从业务方面，DCI 如何助力 DDD 战术设计 3. 从实现方面，DCI 如何助力 DDD 代码实现 4. 通过一个典型的 DDD/DCI 实践案例，将各部分知识点串起来 5. C++/Go/Python 版案例代码关键点对比 6. 核心知识点提炼

这是写给 0 基础同学的 MongoDB 快速入门文章。内容从文档 CRUD 到流式聚合操作；从执行计划、索引、数据模型到复制集；从分片、访问控制到数据备份与还原。全篇近 5 万词的内容覆盖了 MongoDB 的大部分知识点，完全满足日常开发的要求。 为什么选择本篇 Chat？ - 内容类似的 MongoDB 教程动辄几百元 - MongoDB 官方文档晦涩难懂 - 网上其他文章不够全面，难以形成体系化知识 - Chat 中的示例代码可以直接复制使用，方便练习 - MongoDB 内容繁多，自学者不确定需要学习哪些知识 在本场 Chat 中，你将收获： - 文档的 CRUD 操作和 Cursor 对象 - 掌握流式聚合操作，轻松面对任何数据处理需求 - 了解 MongoDB 的查询效率和优化 - 如何提高 MongoDB 的可用性 - 如何应对数据服务故障 - 理解 MongoDB 的访问控制 - 学会用数据模型降低数据冗余，提高效率 - 掌握 mongodump 数据备份与还原方法 适合人群： - 对 MongoDB 感兴趣的 0 基础开发者 - 有一定基础，想要全面了解 MongoDB 的开发者

长期以来，百度在大量的软件开发经验中总结了体系化的 DevOps 实施方法，有效帮助提高软件开发效率和产品质量。本次分享内容主要包括百度 DevOps 实施，提升工程能力的策略和工程实践这两部分。 通过本场 Chat，您将在以下几个方面获得收获： 1. 百度如何定义研发组织的工程能力并与业务目标进行挂钩； 2. 百度如何系统性的实施 DevOps，提升工程能力； 3. 百度在 DevOps 工具链建设上的心得； 4. AI 服务如何实施 DevOps； 5. 百度的研发工程师在工程能力方面的要求。 本场 Chat 受众人群：IT 部门经理、研发经理、测试经理、DevOps 实施负责人和工程效率部门成员。 ---- **讲师介绍** 王一男，百度工程效能部资深产品架构师，效率云产品架构师 金锐，百度工程效能部资深敏捷教练，效率云产品运营总监

领域驱动设计战术部分，是一组面向业务的设计模式，是基于技术的一种思维方式，相对开发人员来说更接地气，是提升个人格局比较好的切入点。 该文章为战术模式的第二篇，重心讲解值对象模式。 值对象经常被掩盖在实体的阴影之下，但它却是非常重要的 DDD 概念。 值对象不具有身份，它纯粹用于描述实体的特性。处理不具有身份的值对象是很容易的，尤其是不变性与可组合性是支持易用性的两个特征。 通过本 Chat，您可以： 1. 理解值对象 2. 何时使用值对象 3. 实现值对象 4. 值对象建模模式 5. 值对象持久化 6. 值对象其他用途 7. 小结

点赞服务在社交类平台中，是一个最常见的功能。每天会有成千上万的用户对其进行操作，在这看似简单的功能背后，蕴藏了不少设计哲学。让我们从领域驱动设计出发，从零设计、开发一套高性能的通用点赞服务。 通过本 Chat 您将学习到： 1. 领域驱动设计核心组件及应用 2. 领域事件实战 3. CQRS 架构实战 本 Chat 主要面向于中、高级程序员；或对高性能系统设计有兴趣的码农。

短链接是指将原本较长的网址转化成较短的网址，从而便于用户的记忆与社交软件上的传播。是互联网营销的重要支撑模块，我们将从零开始设计开发一套高性能多场景支持的短链接服务。 通过本 Chat 您将学习到： 1. 短链接服务工作原理 2. Number 生成器 3. 基于 Redis 和 Protobuf 的分布式缓存加速 4. 基于 Guava 的本地缓存加速 5. 基于策略模式的多场景支持

随着 Spring 官方对 DDD（领域驱动设计）的不断支持，使用领域设计进行技术选型变的越来越可行，领域驱动在面对复杂快速变化的场景中有着独特的优势，本文将通过实际工作中供应链系统的一个模块来让大家熟悉这门技术的使用。 通过本 Chat 你将会了解： 1. Spring Data JPA 对领域驱动设计的支持； 2. 基于事件模型的设计； 3. 如何将 Service 层原来冗余的代码进行拆解； 4. 使用 Querydsl 进行查询的封装； 5. 出入库、商品属性、商品规格的设计； 6. 生产级别的源代码分享。

微服务的改造我们更多的看到的案例分享是一个结果，很难观察其过程以及中间发生的事情。本次介绍的案例是我在过去服务的一个客户的 5 年的微服务演进历程。 本系列共计 4 篇，分别是《[《我们如何衡量一个微服务实施的成功》](https://gitbook.cn/m/mazi/activity/5bc2b6bf27238c76c6782a4c)，[《成功微服务实施的技术演进》](https://gitbook.cn/m/mazi/activity/5bf8c0d2c10964211ef33ae0)，[《成功微服务实施的组织演进》](https://gitbook.cn/m/mazi/activity/5c0e4c4ff0922e2d7413a402)，《微服务演进中的经验和反思》。本场 Chat 是第四篇《微服务演进中的经验和反思》，由于保密的原因，具体的客户、项目、人员名称均为化名。 在演进的过程中，我们也获得了很多教训。我把这些教训整理出来，分享给大家。本场 Chat 首先会和大家分享以下内容： 1. 按需拆分微服务； 2. 微服务的合并； 3. 采用六边形架构； 4. 尽早对齐“统一语言”； 5. 不要过早的开发出统一化的工具； 6. 越来越厚的微服务平台。

本系列共计 4 篇，分别是[《我们如何衡量一个微服务实施的成功》](https://gitbook.cn/m/mazi/activity/5bc2b6bf27238c76c6782a4c)，[《成功微服务实施的技术演进》](https://gitbook.cn/m/mazi/activity/5bf8c0d2c10964211ef33ae0)，《成功微服务实施的组织演进》，《微服务演进中的经验和反思》。本场 Chat 是第三篇《成功微服务实施的组织演进》，由于保密的原因，具体的客户、项目、人员名称均为化名。 一个良好的微服务组织结构和工作流程在很大程度上决定了微服务的架构在开发和运营上的工作模式。通过本场 Chat 你可以了解一个微服务架构团队的演进流程和工作流程。以及这样的团队是如何支撑一个微服务架构的。 本场 Chat 首先会和大家分享以下内容： 1. 微服务开发团队的演化过程； 2. 微服务的团队的大小的原则； 3. 微服务团队中的角色分工； 4. 微服务团队的工作流程和节奏； 5. 树立起微服务的交付规范； 6. 演进中的组织。

ThoughtWorks 技术雷达第 19 期发布了。仔细阅读过的朋友可能和我的感觉一样，会发现大部分条目都是和微服务和 DevOps 相关，但这些条目散落在不同的象限里。 本场 Chat 将通过以下五个主题将这些散落在不同象限的条目进行重组。 1. DevOps 合作新实践； 2. 云计算新实践； 3. 容器新技术和实践； 4. 微服务及其误区； 5. 安全。 通过本场 Chat 你可以了解 DevOps 各方面技术的发展动向。

微服务的改造我们更多的看到的案例分享是一个结果，很难观察其过程以及中间发生的事情。本次介绍的案例是我在过去服务的一个客户的 5 年的微服务演进历程。 本系列共计 4 篇，分别是[《我们如何衡量一个微服务实施的成功》](https://gitbook.cn/m/mazi/activity/5bc2b6bf27238c76c6782a4c)，《成功微服务实施的技术演进》，《成功微服务实施的组织演进》，《微服务演进中的经验和反思》。本场 Chat 是第二篇《成功微服务实施的技术演进》，由于保密的原因，具体的客户、项目、人员名称均为化名。 通过本场 Chat 你可以了解一个组织是如何从一个单体的，多系统集成的架构转变成为一个微服务架构的。 本场 Chat 会和大家分享以下内容： 1. 通过度量驱动架构的微服务化； 2. 微服务平台的演进； 3. 数据库的独立演进； 4. 服务间的轻量级通信； 5. 微服务的全链路跟踪。

云计算像水、电、气一样提供计算、存储和网络等基础资源，而引领云市场的企业自然会成为水厂、电网和气站一样的基础设施，这意味着什么呢？意味着除了现在必缴的水费、电费、气费、话费和网费之外，我们每个月又多了一项必须缴纳的云费，这真是一个风云变幻的大时代！ 往日的巨头们希望再续辉煌，新进的创业者渴望乘势逆袭，大家凭借资本或知本纵横天下，作为云原生应用架构的微服务领域也是战火纷飞、硝烟弥漫。由 RPC 框架演进而来的 Dubbo，由开发框架演进而来的 Spring Cloud，以及扛着新一代微服务架构 Service Mesh 旗帜闪耀登场的 Istio 等等，微服务相关的技术产品层出不穷，面对如此多的选择你是否感到手足无措？ “所谓的大时代，不过就是一个选择，或去或留，我选择了留在属于我自己的年月，那是我最开心的日子”，生活在记忆里不是我的选择，面对云计算这个IT人的大时代，我选择重新出发。让我们一起拨开云雾进一步认识微服务，不止于仅做这个大时代的见证者，还要做一个优秀的参与者和建设者： 1. 微服务架构都有哪些组件构成？ 2. 微服务框架与 PaaS 平台的关系？ 3. 微服务框架彼此有什么异同点？ 4. 微服务框架对比各有什么优势？ 5. 微服务框架的演进和融合方案？ 6. 如何选择最适合的微服务框架？ 学习是反人性的，改变认知也是一个既痛苦又漫长的过程，但我更憧憬未知的快乐……你呢？

微服务的改造我们更多看到的案例分享是一个结果，很难观察其过程以及中间发生的事情。本次介绍的案例是我在过去五年服务的一个客户，该客户经过了 5 年的微服务改造。作为一个见证者，从一个见证者的角度看到了该客户 5 年之间的变化，把我在实践和观察微服务的心得总结下来，分享给大家。通过本次分享，你可以了解到在做微服务的架构改进前中后需要注意的不同方面的问题、成本、收益，以及团队和技术的决策和养成。 本系列共计 4 篇，分别是《我们如何衡量一个微服务实施的成功》《成功微服务实施的组织变化》《成功微服务实施的技术变化》《微服务转型中的经验和反思》。本场 Chat 是第一篇《我们如何衡量一个微服务实施的成功》，由于保密的原因，具体的客户、项目、人员名称均为化名。 本场 Chat 首先会和大家分享一下这个客户和项目的大概背景。接着会和大家简单介绍一下微服务架构的演进的成本分析。然后和大家分享从组织和技术上可以看到的变化。 本场 Chat 你会了解到以下内容： 1. 案例背景 2. 微服务架构演进的成本分析 3. 微服务改造后的组织改进变化 4. 微服务改造后的技术改进变化