数据密集型应用系统设计 - Designing Data Intensive Applications
数据密集(Data-Intensive)与计算密集(Compute-Intensive)是当今两大负载类型。前者以大数据为代表,后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 另一个电子版本。 前言 数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率;与之对应的是计算密集型应用,CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的(NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架)。 每一种技术都基于一定的设计理念,而且只适用于特定的场景。 不要过度优化。 可靠、可扩展与可维护的应用系统 现在的典型系统架构已经很明确了,因为业界已经有成功的案例,对这些组件做了很好的抽象,我们只要做好拿来主义就行了。 可靠性(Reliability) fault tolerance 和 resilience 是系统的容错的体现。 硬件故障 对于大型 IDC,即使磁盘的 MTTF 很高,磁盘数量大了以后,每天发生磁盘损坏也是正常的事情。 硬件容错的方案是制造冗余(冗余磁盘、冗余电源)。 软件容错是第二种方式。 软件错误 软件错误...
现代垃圾收集器
所有的垃圾收集器,都基于弱分代假设。实际的垃圾回收效率取决于堆内对象的分布状况。垃圾回收并不能解决内存泄漏或者应用程序逻辑的不良分配习惯问题,要处理 JVM 内存回收问题的根本方法是对程序进行调优。 有几个常用原则: 减少临时对象,尽量复用内存。 使用对象池。 主动提前释放对象。 主动 gc。 好的代码比 tuning 更重要。 选 gc 算法比 tuning 参数重要,tuning 参数是最后一步。 其他情况,可以通过 tuning garbage collector 来解决。 操作系统的影响 SWAP 可能会显著增加 GC 时间,因为被换出的堆还要被换入。 美团的实践 参考: 《从实际案例聊聊Java应用的GC优化》 《Java中9种常见的CMS GC问题分析与解决》 Minor GC Major GC Full GC 垃圾收集器分类 可以看到一个现象:在大部分时候,g1 比 CMS 快,但极端的百分位里,CMS 比 g1 快。 出处见这里。 常用工具 命令行终端 标准终端类:jps、jinfo、jstat、jstack、jmap 功能整合类:jcm...
MySQL 的配置
123456789101112131415161718-- 查看自动提交SELECT @@autocommit-- 查看全局隔离级别和会话隔离级别SELECT @@global.tx_isolation, @@tx_isolation;-- 查看引擎的事务状态,这里可以看出死锁日志,但需要 PROCESS privilege(s)show engine innodb status# 查看表详情show table status like 'dept_emp'# 查看当前存储引擎默认的行格式SHOW VARIABLES LIKE '%innodb_default_row_format%'# 查看全部 binlog 文件show binary logs;# 查看最新的binlog,带有 positionshow master status; # 查看某个 binlog 的内容show binlog events in 'binlog.000156';
异地多活与单元化
背景介绍 名词解释 ldc logical data center idc internet data center ldc 是 idc 的进化版,是一种单元化部署方案。 扩展模式 vs 镜像模式 扩展模式是把服务/数据库分拆,然后部署到不同的机房里面,相当于放大了一个物理机房。 镜像模式是每个机房里部署的服务都是一样的,每个机房承担一定流量。 镜像模式的容灾效果更好,难度在如何切分流量上。容灾还要考虑机房级容灾、部署地容灾的问题。多地部署带来距离,距离带来延时,延时带来 replica 的风险。 单元化部署 所谓 cell,是一个能完成所有业务操作的自包含集合(每个单元,都是其他单元的镜像)。一般的 soa 架构,服务是分层的,而且每一层的任一节点都可以被其他机房调用。而单元化部署的结果是,本单元的上层节点,只会调用本单元的下层节点。它具有一个站点全部的功能,但不具有一个站点全部的流量。 这种单元化部署实际上就要求底层的数据也要做 sharding。单元化的结果是,数据库连接可以更好地被复用-多个单元互相跨 db 连接,其实很浪费资源。 单元化是按核心数据维度,对业务系统的部署...
压力测试需要关注的注意事项
真正的高可用高并发架构,只有在压测中才能显示合理性和不合理性。有时候我们怀疑积压来自于服务,其实可能来自于数据,或者缓存或者消息队列。 确认核心链路的范围:纵向看,深度到哪里(哪里已经不是本架构域需要关注和改造的范围,哪里需要 mock);横向看,一个请求会涉及多宽的 scope(服务的宽幅)。产出是:需要关注的服务和拓扑结构。 寻找压测指标:容量应该在什么条件下摸到多高。高度由现在的日常业务高峰和大促的流量增长综合评估得出,首先确定业务系统应该支持的 qps/tps 数量。然后考虑容灾等级,即允许在几个机房、几台机器挂掉以后,服务还能正常运行。如果一个服务应该支持的日常峰值(考虑大促),乘以冗余数量(如果是两地三中心,应该考虑将单机房的压测峰值乘以 3)。 确定压测过程中压测指标: VM 性能指标项: fullgc 次数 gc time(总数和平均值) gc count(注意和同环比看是不是显著增加,是不是有可疑的波动) block 状态线程数(看看系统是不是已经达到吞吐瓶颈了) 服务性能指标项: 接口 TP999 的响应耗时(没有办法统计这项指标的可以看 MAX 和...
常见的服务器调用堆栈
自顶向下调用 $是内部类的意思 $$是由 Lambda 生成的内部类的意思。当然 Spring 的 CGLIB 可以自己控制 naming pattern。 内部类生成的类名后往往带有一个数字,这个数字表示编译器生成这个内部类的顺序 Thread.run() ThreadPoolExecutor$Worker.run() ThreadPoolExecutor.runWorker() Netty.DefaultServerHandler.run() Netty.DefaultServerHandler.handleRequest() ThriftServerPublisher$MTProccessor.process() Thrift 接口$Processor.方法名() com.sun.proxy$Proxy 数字.方法名() XXXServiceImpl$$EnhancerBySpringCGLIB$$1fb0b39f.被拦截的方法 ThriftInvoker.invoker() RhinoLimiterFilter.filter() ThriftInvoker.invoke...
CSP
何谓 CSP CSP (内容安全策略)的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。它的实现和执行全部由浏览器完成,开发者只需提供白名单的配置也就是CSP规则,下图为Github使用的CSP规则。 Content-Security-Policy: default-src ‘none’; base-uri ‘self’; block-all-mixed-content; connect-src ‘self’ uploads.github.com www.githubstatus.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-product...
高性能 MySQL
译者序 MySQL 最初是放在 LAMP 里一起讨论。 淘宝网最初使用 LAMP 架构,使用 MySQL 4.0。03 年底改用 IOE,从 08 年开始又筹划去 IOE。09 年的时候 MySQL 的架构也从垂直拆分改成水平拆分。2012 年 MySQL 的单库已经有了 6.5 万的 QPS。 本书是 mysqlperformanceblog.com 的几个专家(同样也是 percona 的创始人)的作品,对于 InnoDB/XtraDB 等存储引擎的性能优化和诊断方法有很深入和详细的介绍。 推荐序 作者在性能优化领域工作多年,这本书诞生于 MySQL 还没有什么可扩展性和可测量性的时代,直到现在这些方面已经有了长足的进步。说到合理的方法,他们简直把这件事当成了科学,首先定义需要解决的问题,然后通过合理的猜测和精确的测量来解决问题。 性能优化 = 定义问题 + 猜测 + 测量 要关注: 吞吐量 响应时间 吞吐量 = 线程数/响应时间 追求新技能,如排队理论对性能的影响。 MySQL 的架构和历史 MySQL 能够应用的场景: 嵌入到应用程序中 数据仓库 内容索引 部署软件...
Spring IOC
总体的类图 spring-Ioc Bean 工厂提供 IOC 基本功能,Context 是全功能的 BeanFactory,是应用程序的全部上下文。 扩展点和生命周期钩子 Spring的扩展点.xmind 加载顺序: 获取工厂 准备工厂 后处理工厂 InstantiationAwareBeanPostProcessor.postProcessBeforeInstantiation,返回 object。 构造器 InstantiationAwareBeanPostProcessor.postProcessAfterInstantiation,返回布尔值。 populateBean(注入 @Autowired,类内第一个方法),实际上调用的是 InstantiationAwareBeanPostProcessor.postProcessProperties InitializingBean: 各类 aware 方法注入 BeanPostProcessor.postProcessBeforeInitialization 的后处理器(@PostConsstruct) a...
Spring 与数据库
Java 执行事务的过程 1.获取连接 Connection con = DriverManager.getConnection() 2.开启事务con.setAutoCommit(true/false); 在 Spring 事务里(如 DataSourceTransactionManager 的 doBegin 方法)里,总是会显式地 con.setAutoCommit(false);(不然哪有事务可言)。 3.执行CRUD 4.提交事务/回滚事务 con.commit() / con.rollback(); 5.关闭连接 conn.close(); 本文涉及到的类型的类图 Spring 的事务管理核心类型和流程 DataSource 不同的数据源诞生不同的 DataSource。默认的 TransactionManager 本身是期待一个名叫“datasource”的数据源的。 FactoryBean 不同的 DataSource 装入不同的 FactoryBean,比如 JPA 的 EntityManagerFactory。 PlatformTransaction...