前言虽然我们可以通过很多方式增加存储系统的性能，但某些场景下，只通过存储系统提升性能是不够的： 需要通过复杂的运算得出结果的数据 读多写少的数据：比如明星微博，只要一次Insert,但是却可能需要几千万次的select，对数据库的压力很大

关系型数据库的缺点关系型数据库已经非常成熟，但是并不是完美的，仍然有以下缺点： 关系型数据库存储的是行记录，无法存储数据结构。 关系型数据库的Schema扩展非常不方便。 关系型数据库的Schema是强约束，无法操作不存在的列。当要扩

前言读写分离就是将数据库的读写操作分配到不同的机器，原理图如下： 读写分离的基本实现： 数据库服务器搭建集群模式，一主一从或一主多从。 数据库主机负责写，数据库从机负责读。 数据库主机通过复制将数据同步到从机，每个数据库服务器都保存所有的

前言读写分离分散了数据库的读写压力，但并没有降低数据库的存储压力。当数据量达到上亿的时候，单台数据库就会成为瓶颈。 单表数据量太大的话，读写性能会很差。增加索引，索引也会很大。 数据库文件太大的话，备份和恢复都要花费很多时间。 数据库文件

前言在完成备选方案的设计和选择后，我们需要将备选方案进行细化，使得备选方案变成一个可以落地的方案。这就是我们要讲的详细方案的设计。 架构设计第4步：详细方案设计简单的来说，详细方案设计就是将方案涉及到的关键细节给确认下来。详细方案里也有一些

引言在完成备选方案的设计后，如何挑选一个最终方案也是一个很大的挑战，主要是由于： 每个方案都是可行的，如果不可行的话就不可能成为备选方案。 没有哪个方案是完美的。每个方案都可能有缺陷。 评价标准比较主观，因此很容易的评审会议上出现架构师争

架构设计第 2 步：设计备选方案成熟的架构师需要对已经存在的技术非常熟悉,对已经验证过的架构模式烂熟于心。然后根据自己对业务的理解,挑选合适的架构模型进行组合,再对组合的架构模型进行修改和优化。 经过时间的考验，已经被验证的架构模型有很多。

架构设计第一步：识别复杂度前文讲过，架构设计的本质目的是为了解决软件系统的复杂性,所以我们在设计架构时首先要的就是识别系统的复杂性。只有正确分析出软件系统的复杂性,后续的架构才不会偏离方向。如果一个系统的复杂性是功能耦合严重，逻辑复杂，而架

前言本文主要对dubbo做一个简介和一个入门实例。 dubbo是什么?Dubbo是阿里巴巴开源的一个高性能的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。Dubbo是一款高性能、轻量级

从git下载cas，下载的是4.1.x版本。它是用maven管理Jar包的最后版本。 导入到idea中。 找到cas-server-webapp子项目，修改pom.xml,增加tomcat7 plugin启动 <plugin> &

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hex