每年一次的双十一大促临近，因此上周末公司组织了一次技术交流闭门会，邀请了电商、物流、文娱内容、生活服务等知名一线互联网公司的技术大牛，一起探讨了一些大促稳定性保障相关的技术话题。
前文提到异地多活的几种型态和基于OceanBase实现方案。这里再总结一下基于其他分布式数据库（MySQL）实现异地多活时要考虑的点。本文不讨论为什么做异地多活，可以参考末尾的文章。
小红书使用 TiDB 历史可以追溯到 2017 年甚至更早，那时在物流、仓库等对新技术比较感兴趣的场景下应用，在 2018 年 5 月之后，我们就开始逐步铺开，延展到其他适合 TiDB 的场景中去。截止目前，小红书使用的 TiDB 节点数在 200+ 个，未来也有更大扩展空间。
当前，随着电商节日的增多（6.18、双十一、双十二）、平台拉新趋于频繁，大促活动也越来越普遍。作为一个电商平台，每年都会有一次，甚至几次的流量“大考”。数据库作为系统的重要节点，其稳定性和性能格外重要，数据库的全力保障是一个大的挑战。电商大促，这场没有硝烟的战争很多人已有体会，在此不再赘述。现在，我们直接切入主题--数据库如何 积极应对，全力保障 大促活动。这个题目分解为三个部分进行讲解： 第一部分，准备工作；第二部分，大促进行时；第三部分，大促后复盘。
一年一度的双十一又双叒叕来了，给技术人最好的礼物就是大促技术指南！而经过这些年的发展，大促早已不仅仅局限于电商行业，现在各行各业其实都会采用类似方式做运营活动，汽车界有 818，电商有 618 、11.11 等等，各种各样的大促场景，对包括数据库在内的基础软件提出了很多新挑战，同时也积累了诸多最佳实践。
数据分片后，对数据的查询就没那么自由。如订单表按用户ID作为Sharding Key，就只能按用户维度查询。我是商家，我想查我店铺的订单，做不到。（强行查也不是不行，在所有分片上都查一遍，再把结果聚合，又慢又麻烦，实际意义不大）
几年前我曾经服务过的一家电商公司，随着业务增长我们每天的订单量很快从30万单增长到了100万单，订单总量也突破了一亿。当时用的Mysql数据库。根据监控，我们的每秒最高订单量已经达到了2000笔（不包括秒杀，秒杀TPS已经上万了。秒杀我们有一套专门的解决方案，详见《秒杀系统设计～亿级用户》）。不过，直到此时，订单系统还是单库单表，幸好当时数据库服务器配置不错，我们的系统才能撑住这么大的压力。
最近跟一位读者聊天，小哥非常郁闷，公司的Redis宕机了，线上业务受到了影响，老板非常愤怒，小哥担心会不会被辞退！
同盾科技是中国领先的人工智能科技企业。为了确保服务的低延迟和高可用性，同盾的技术团队不断寻找最佳的技术架构。经过长时间调研，他们最终选择了新一代分布式数据库 TiDB 作为离线层的核心数据库，基于 TiDB 打造的实时数据架构为风控智能决策保驾护航。
TiCDC 是一个通过拉取 TiKV 日志实现的 TiDB 增量数据同步工具，具有还原数据到与上游任意 TSO 一致状态的能力，同时提供开放数据协议，支持其他系统订阅数据变更。TiCDC 运行时是无状态的，借助 PD 内部的 etcd 实现高可用。TiCDC 集群支持创建多个同步任务，向多个不同的下游进行数据同步
TiCDC 是一个通过拉取 TiKV 日志实现的 TiDB 增量数据同步工具，具有还原数据到与上游任意 TSO 一致状态的能力，同时提供开放数据协议，支持其他系统订阅数据变更。TiCDC 运行时是无状态的，借助 PD 内部的 etcd 实现高可用。TiCDC 集群支持创建多个同步任务，向多个不同的下游进行数据同步。
面对一个庞然大物，如果没有一个合理的分工分层。任何一个小小失误都会被无限放大，酿成巨大灾难。
采访嘉宾 | 金思宇、陈贞宝、胡强忠 编辑 | 辛晓亮 大型电商系统并非一开始就具有完整设计的高可用特性，而是随着用户的不断增加与业务的快速增长逐步演进与完善的。当前高可用架构体系是互联网企业系统架构的基础要求，随着公司的业务发展，尤其是对于电商平台，每次发生稳定性故障带来的影响越来越大，提供稳定的服务，保证系统的高可用已经变成了整个技术团队需要面对的挑战。 基于此，我们深度采访了得物技术团队核心成员，探索他们在高可用架构上的实践、演进，深入了解大促备战是如何进行的，异地多活体系是如何建设的，全链路
伴随着网站业务发展，需求日趋复杂多样并随时变化。传统静态化方案会遇到业务瓶颈，不能满足瞬变的需求。因此，需要一种能高性能实时渲染的动态化模板技术来解决这些问题。本文和大家分享一下最近一年做的京东商品详情页的架构升级的心路历程。
互联网时代除了业务迭代速度快，还有就是数据增速也比较快。单应用、单实例、单数据库的时代早已不复返。现在，作为技术研发，如果参与的项目没有用到分库分表，都不好意说自己做过大项目。
本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
由于此订阅号换了个皮肤，导致用户接受文章不及时。读者可以打开订阅号「Web项目聚集地」，选择置顶（标星）公众号，重磅干货，第一时间送达！
本文以淘宝为例，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
本文以设计淘宝网的后台架构为例，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知。文章最后汇总了一些架构设计的原则。
淘宝开放平台（open.taobao.com）是阿里系统与外部系统通讯的最重要平台，每天承载百亿级的API调用，百亿级的消息推送，十亿级的数据同步，经历了8年双11成倍流量增长的洗礼。本文将为您揭开淘宝开放平台的高性能API网关、高可靠消息服务、零漏单数据同步的技术内幕。
TEG为腾讯提供互联网行业全方位的运营解决方案和服务支持，运营着亚洲最大的网络、服务器集群和数据中心，拥有业内领先的基础架构云运营平台、云数据处理平台、互联网海量应用支撑服务平台，为亿级用户提供云计费服务和安全保障。这背后离不开一群7*24小时默默耕耘，负责标准化模块化数据中心网络架构、大集群平台自动化建设与运营，以及运营系统相关规划和建设，提供高可用保障体系的伙伴们。
本文以设计淘宝网的后台架构为例，介绍从一百个并发到千万级并发情况下服务端的架构的14次演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知。文章最后汇总了一些架构设计的原则。
百科词条：https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99[1]
之前有读者留言让写一篇大型网站的架构演进过程，发现下面这篇文章讲解得很详细，特此分享给大家，相信看完会有所收获。
我们都知道互联网数据有个特性，大部分场景都是 读多写少，比如：微博、微信、淘宝电商，按照 二八原则，读流量占比甚至能达到 90%
实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
哈喽，小伙伴们好呀。我是狗哥，之前有读者留言让写一篇大型网站的架构演进过程，发现下面这篇文章讲解得很详细，特此分享给大家，相信看完会有所收获。
最近看到一篇关于淘宝架构变化的文章，介绍了淘宝是如何一步步从单体架构变成支撑千万级并发的系统，在这里分享给大家。技术服务于业务，任何一次架构的演变，其实都是为了解决当时存在的问题。
下文将介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
爆发式增长的红利过去了，要想持续的营收增长，精细化的营销是必须的，巨大的流量主，广告主要精准触达用户，对长效ROI的需求日益增长，提高投放效果，那么RTA新的玩法就出现了，其实不难理解，个性化的精准投放实现在广告主侧实现。
“all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
有赞是提供商家 SAAS 服务，随着越来越多的商家使用有赞，搜索或详情的需求也日益增长，针对需求及场景，之前提到过的订单管理架构演变及 AKF 架构等在这两篇文章里已经有所体现，而这些数据的查询来自于不同的 NoSQL，怎么同步这些非实时存储系统将是一个很有趣的事情。
新一轮“618”大促火热进行中。此前，各大电商平台纷纷宣布，今年将取消往年的预售模式，改为直接开售配合官方补贴的策略。外部多将这一变化解读为行业顺应市场呼唤、积极创新的结果。
最近一直在忙618大促的全链路压测&稳定性保障相关工作，结果618还未开始，生产环境就出了几次生产故障，且大多都是和系统稳定性、性能相关的bad case。生产全链路压测终于告一段落，抽出时间将个人收集的稳定性相关资料整理review了一遍，顺带从不同的维度，谈谈稳定性相关的“务虚”认知和思考。。。
分享一篇讲解大型网站的架构演进过程的文章，相信看完会有所收获。 文章在介绍一些基本概念后，按照以下过程阐述了整个架构的演进过程： 单机架构 第一次演进：Tomcat与数据库分开部署 第二次演进：引入本地缓存和分布式缓存 第三次演进：引入反向代理实现负载均衡 第四次演进：数据库读写分离 第五次演进：数据库按业务分库 第六次演进：把大表拆分为小表 第七次演进：使用LVS或F5来使多个Nginx负载均衡 第八次演进：通过DNS轮询实现机房间的负载均衡 第九次演进：引入NoSQL数据库和搜索引擎等技术 第十次演进：
本文以某个电商为原型，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了对系统的要求。
内部的API可能是由很多种不同的协议实现的，比如HTTP、Dubbo、GRPC等，但对于用户来说其中很多都不是很友好，或者根本没法对外暴露，比如Dubbo服务，因此需要在网关层做一次协议转换，将用户的HTTP协议请求，在网关层转换成底层对应的协议，比如HTTP -> Dubbo, 但这里需要注意很多问题，比如参数类型，如果类型搞错了，导致转换出问题，而日志又不够详细的话，问题会很难定位
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
