守株阁

MySQL 高可用架构的历史 MySQL 自带的主从复制机制，本身并不能实现自动高可用。 早期使用开源组件来搭 MySQL 集群的方案，使用 MMHA。当代 MySQL 官方自己主推的方案是 MySQL cluster。这些老的方案，优先保证MySQL服务的持续可用，在异常切换情况下，可能出现主机上部分数据未能及时同步到从库，造成主从切换后数据丢失。但是包括金融支付在内的一些业务，对于数据库服务既要求持续可用、也要求数据强一致（可以在性能上做出一些让步）。 因此，当代的 MySQL 官方提供了组复制（MySQL Group Replication）的方案，构建了新一代的 MySQL 高可用强一致服务。 Master-Slave（MS）架构高可用概述 MS架构高可用基础 高可用MySQL是依赖复制（Replication）技术实现的，复制解决的基本问题就是，让一台数据库服务器的数据同步到其它服务器上。MySQL数据库的复制有如下三个步骤。 在主库上把数据更改记录到二进制日志（Binary Log）中（这些记录被称为二进制日志事件）。 备库将主库上的日志复制到自己的中继日志（...

秒杀的实质 秒杀的实质，是围绕库存管理展开的并发读写 如果架构设计里面包含商品系统，包含库存，秒杀就要解决库存热点行高并发读写问题。 秒杀的底线是：不能超卖。qty库存 ≥ qty卖出 && qty库存 - qty卖出 ≈ 0。 秒杀能够容忍的一些思路：渐进趋于一致，允许漏卖。 秒杀架构的特性 高性能：秒杀架构要承载的访问流量比平时高出许多倍，涉及大量的并发读和并发写，因此支持高并发访问非常关键。 一致性：秒杀活动中有限数量的商品在同一时刻被很多倍的请求同时扣减库存，在大并发更新的过程中要保证数据准确，不能发生超卖的问题（超卖，本来应该卖完下架的商品，在前台展示依然有库存，依然不停的被卖出），即库存是多少，理应卖出多少（qty库存 ≥ qty卖出 && qty库存 - qty卖出 ≈ 0）。 高可用：秒杀架构虽经多次打磨优化，但现实中总难免出现一些考虑不到的情况，要保证系统的高可用，还要设计一个兜底预案，以便在最坏的情况发生时仍能从容应对。 秒杀技术难点 在有限的资源下，秒杀链路承载合理的最大流量。 大并发下扣减库存准确，“一致性...

语义 小步语义 小步语义类似对代数式迭代求值。 大步语义 大步语义的意思是，对于大的表达式，先求它的小表达式，然后把结果结合起来得到最终的答案。这通常意味着递归 操作语义（operational semantic） 想象一个理想、抽象的计算机，操作语义为程序在某些机器上的执行定义一些规则。 指称语义（denotional semantic） 用一种低级、更形式化的语言来解释当前的语言。 状态机的分类 确定性有限自动机 finite state machine -> finite automaton deterministic finite automaton 是确定性有限自动机的意思 我们的领域模型的状态机最好是这种状态机。 非确定性有限自动机 NFA 能被一台特定机器接受的字符串集合称为一种语言：我们说这台机器识别了这种语言。 任何 NFA 等价于 DFA 确定性下推自动机 PushDown Automaton pda。 这种状态机可以处理无限多的中间状态。 确定型图灵机 Deterministic Turing Machine DTM 可以解决所有可判定/可计算问题 停...

from：http://www.blogjava.net/sean/archive/2009/09/28/296825.html 最近围观一本JavaScript的书籍引发的争论，一不小心碰到一篇讲编程语言类型系统划分的帖子，回想起当年还在公司内部的Tech Session上主讲过这个话题，不过只涉及到静态/动态、强类型/弱类型，远没有这位仁兄总结的那么全面。 原文链接 http://www.reddit.com/r/programming/comments/63tnv/bruce_eckel_33104_im_over_it_java/c02qx55 不多废话，直入正题： [维度一] Static vs Dynamic Typing 静态类型和动态类型，区分的关键点为编译期或运行期确定类型：静态类型在编译期确定，动态类型在运行期确定。 静态类型代表 Java、Scala、Haskell 动态类型代表 Ruby、Python、Erlang [维度二] Strong vs Weak Typing 强类型和弱类型，区分的关键点为运行时是否自动转换到与实际类型不符的类型：强类型要求手工...

无人区 所有伟大的创新、公司和企业家都不是在既有经验、已有成果之上取得的成绩，而是在毫无经验、毫无基础、毫无积累的状态下取得成功。 所有伟大的机会都来自于未来、来自于未知，而非来自于既有。 什么叫逆向思维？在大家恐惧的时候，你需要乐观，在大家都是乐观的时候，你可能要恐惧，类似于古人曾提及的“乐极生悲，否极泰来”，其实讲的就是这个道理。大众的一个惯性思维是“追涨杀跌”，在大家都认为情况乐观的时候，会引发人们跟风模仿。曾有人以投资为例，大部分老百姓并不懂得投资规律，当看见一堆人跟风投资的时候，你就要非常谨慎，这时候可能正是风险来临的时候。 所以，对我们来讲，在遇到困难时，我们要去思考这件事为什么困难，这困难会持续多久？它是在正确轨迹上的一个困难；还是说这个业务面临一些根本性的挑战，需要一个巨大的变革；还是这条路本身就是一个死胡同？当处于乐观状态时，我们要思考这种乐观状态是否可持续，未来需要做什么才能让这种增长得以保持。历史的无数经验表明，所有的发展都是一种波浪式的发展。可以看到，我们有时候处在一个波浪的波谷，有时候处在一个波浪的波峰，更重要的是，我们要去识别这种波浪是否在逐步升高，而...

问题定义 AP 的出现 在互联网浪潮出现之前，企业的数据量普遍不大。通常一个单机的数据库就可以保存核心的业务数据。那时候的存储并不需要复杂的架构，所有的线上请求(OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。后来业务越来越复杂，数据量越来越大，产生了一个显著问题：单机数据库支持线上的 TP 请求已经非常吃力，没办法再跑比较重的 AP 分析型任务，在这样的大背景下，于是AP开始从TP系统分离，某种程度上，AP是TP的一个分支。 这等于是在存储层做 CQRS 架构设计-另一种方案是在应用层也设计读写分离的架构。 AP的玩法 在这样的背景下，以 Hadoop 为代表的大数据技术开始蓬勃发展，它用许多相对廉价的 x86 机器构建了一个数据分析平台，用并行的能力破解大数据集的计算问题。 TP和AP的联系 虽然 TP 和 AP 开始往独立的方向演进，但是他们的核心都是需要处理数据，所以需要将数据打通。业内普遍玩法将 TP 数据通过 ETL 工具抽取出...

前言 这两周集中时间间歇性读完了《恰如其分的软件架构》这本书。这本书讲的是架构方法，架构方法是一种思维模型（mind set），这种思维模型叫作“风险驱动模型”。 这本书经我们团队的架构师推荐，列在我们团队的集体书目里很久了。但真正去读它、读完它的人又很少。究其原因，还是这本书的内容以谈概念为主，虽然书中举的例子非常生动，仍然始终无法摆脱“为了谈概念而举玩具例子”的问题-这几乎是所有架构书的通病。似乎正统的架构书籍都不可避免地举一些传统行业或者经典软件（比如很多书籍都会反复出现在“xxx 播放器”）的例子。这些软件架构非常经典，可以只用一些小的组件、场景，就讲清楚典型的组件、模式和架构风格的用处。但没有很深的工程/架构经验的读者读这些书的时候，仿佛重新回到了抄书和念书的大学课堂，对于脱离现实的例子只会产生“左耳进右耳出”的感觉。能够温故而知新，是一本书经典化的特征。而能够阅读非入门级的纯理论书籍，则是一个程序员的认知能力和经验达到了一定程度的特征。我读这本书里很多细节还是很痛苦，证明我还是对于形式化的符号（symbol）、记法（notion）还不是很熟悉，而且对于书中运用的问题解...

EBS 的定义 EBS — Elastic Block Storage，简言之就是高可用、高性能、弹性可扩展的分布式块存储服务。对于业务来说，它就是一块磁盘，只不过将业务数据存储于远端网络节点，但是使用方法和体验与访问本地磁盘一样。 EBS 可以作为容器的存储盘，可以解决： 有状态容器的状态存储问题 海量存储问题：邮件系统、监控平台、数据库、用户录音、集成测试平台、MySQL 备份（需要测试 OLTP/OLAP 的交互操作和在线交易性能） EBS 的文件系统结构 在EBS分布式块存储系统中，最终存储业务写入数据的服务是ChunkServer。 单机存储引擎位于每个ChunkServer上，业务的数据读写请求到达ChunkServer后，最终通过单机存储引擎与操作系统文件系统交互来写入或读取数据。 业务申请的每一块ebs网络盘在我们的系统里都对应一个Volume。Volume本身是一个逻辑概念，每个Volume被切分成多个Chunk，Chunk最终对应到ChunkSever上文件系统中的一个真实文件，因此我们的单机存储引擎最终会管理这一系列Chunk文件的创建，读写，删除等操作...

介绍下使用到的 Gradle 工具 《一篇文章讲清楚Gradle与Gradle Wrapper的区别》 comments： Gradle Wrapper 提供了一种“在本地构建中，使用特定版本的 Gradle 进行构建”的功能。 换言之，对于大多数敏捷迭代的项目而言，应该选择 ./gradlew clean build，而不是 gradle clean build。这样不会遇到 pluginManagement 之类的问题，这样说来，每个项目都是自构建的。 要么 IDE（像 Android Studio）自带 gradle wrapper，要么项目自带一个 gradle/wrapper 文件夹，这个文件夹里指定了 gradle-wrapper.properties。 这个命令专门指定了特定版本的 gradle。-all.jar、-bin.jar、-src.jar 分别代表不同的包。 gradlew是在linux,mac下使用的，gradlew.bat是在window下使用的，提供在命令行下执行gradle命令的功能。-这种 w 的中间层策略，值得我们学习。 每个项目本身都带有特...

弹性问题 弹性服务最好和监控服务、限流服务配合。 弹性服务的监控最好低于限流服务的阈值，否则不会被触发。 要注意扩容阈值和缩容阈值。如果有必要，设置阶梯阈值，离正常值越远的阶梯越不敏感，离正常值越近的阶梯越敏感。阶梯越远，弹性的量应该越大。 注意弹性有静默期，注意发布和弹性静默期之间是相互矛盾的，要相互关闭。 如果有压测标记，注意让弹性扩容监控包括/排除压测流量。 任务调度或者特殊的有状态的中间件依赖的分布式节点应该尽量避免弹入和弹出。 慢预热服务-扩容机器服务可用性差问题 极少部分依赖缓存预热的业务在接入弹性的过程中，在业务代码配置不合理的情况下，可能出现服务节点启动时服务不可用或性能较差的情况。 出现这种问题可以产生如下情况: 服务节点启动后尚未完全预热，大量流量打入导致服务不可用（TP耗时飙升）。 服务依赖数据源尚未初始化完成，服务节点就已注册至服务治理的命名服务器，开始承担流量，但此时服务处于不可用状态（请求异常）。 机器刚刚扩容出来时cpu.busy指标较高，承接流量后影响服务可用性。 此类问题的根本原因是：服务自身预热工作未完成时，处于服务不可用状态，此时不应...