逍遥飞鹤的专栏

在上一篇文章《大型网站系统架构分析》中，介绍了大型网站的系统架构，其中缓存环境非常重要，大型网站往往使用Squid前端缓存服务器群，memcache分布式缓存，负载均衡，CDN等来提升性能。但中小型网站使用这些大家伙就有杀鸡用牛刀的感觉，但毋庸置疑，缓存是需要的，开发者开发程序的时候若没有并发思维，一味注重业务逻辑，往往导致并发用户可能在差不多相同的时间请求相同的数据，网站再请求数据库，如果使用缓

随着乐视硬件抢购的不断升级，乐视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环，保证用户快速稳定地完成支付尤为重要。所以在2015年11月，我们对整个支付系统进行了全面的架构升级，使之具备了每秒稳定处理10万订单的能力。为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑。        一. 分库分表      在redis，memcached等缓存系统盛行的互联网时代，

之前在分布式环境下需要解决session共享的问题，更多的时候我们是使用servlet容器例如tomcat提供的集群配置来解决session的复制问题。今天介绍一种简单的解决方案。http://docs.spring.io/spring-session/docs/current/reference/html5/guides/httpsession.html#updating-depen

转自：http://www.cnblogs.com/mindwind/p/5017591.html京东咚咚架构演进咚咚是什么？咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。 我们首先看看它诞生之初是什么样的。1.0 诞生（2010 - 2011)为了业务的快速上线

1.大型网站电商网站架构案例大型网站架构是一个系列文档，欢迎大家关注。本次分享主题：电商网站架构案例。从电商网站的需求，到单机架构，逐步演变为常用的，可供参考的分布式架构的原型。除具备功能需求外，还具备一定的高性能，高可用，可伸缩，可扩展等非功能质量需求（架构目标）。根据实际需要，进行改造，扩展，支持千万PV，是没问题的。本次分享大纲电商案例的原因电商网站需求网站初

前言我们以javaweb为例，来搭建一个简单的电商系统，看看这个系统可以如何一步步演变。该系统具备的功能：用户模块：用户注册和管理商品模块：商品展示和管理交易模块：创建交易和管理阶段一、单机构建网站网站的初期，我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器，如tomcat、jetty、jboos，然后直接使用JSP/servlet技术，或者使

一、消息队列概述消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。二、消息队列应用场景以下介绍消息队列在实际应用中常用的使用

摘要：本文主要介绍如何理解 Java 应用的扩展方式以及不同类型的扩展技术和具体技巧，介绍一些有关 Java 企业级应用的一般扩展策略。老实说，“可扩展性”是个全面且详尽的话题，而且往往得不到充分理解。人们通常认为可扩展性等同于高可用性，笔者见过编程新手和架构师“老手”都建议将集群作为可扩展性和高可用性的解决方案。建议确实没错，但问题是，人们通常是通过互联网搜索，而非实际理解应用本身的情况来实

缓存缓存 1.1 缓存刷新机制，缓存刷新是指什么时候把数据库中的数据加载到缓存 （1） 定期刷新； （2） 缓存命中失败时刷新； 1.2 在有缓存时的数据写入方式： （1） 同步写入，即缓存和数据库同时被写入，即在应用层进行双写操作，这种方式可以有效保证缓存和DB中数据的一致性，由于这种方式即要更新缓存同时还要更改数据库，其访问效率相对较低，适合读多写少的场景；

转自：http://blog.youkuaiyun.com/houjixin/article/details/53675741本文是对《架构即未来》一书第20章的总结； 1. 立方体扩展是指X、Y、Z轴三个方向的扩展方式； 2. X轴扩展，指水平扩展，这种方式简单易于实现，它要求服务必须是无状态的，部署1个和部署多个是一样的，这样可以根据系统当前的业务承载量来部署所需数量的服务实例，一般情

转自：架构师之路前篇：《无限容量数据库架构设计》《MQ消息可达性+幂等性+延时性架构设计》都收到网友好评：系统性，全局性看问题体会更深刻简单易懂本文再做总结，体系化介绍高可用，高并发，负载均衡的一些架构技术。一、高可用文章：《究竟什么是互联网高可用架构设计》内容：

挑战与解决策略压力挑战： 短暂的高流量，对现有网站业务造成冲击 秒杀是一个网站营销的一个附加活动，时间短，并发量大。 如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。 高并发,数据库高负载 用户秒杀开始前，通过不断刷新浏览器来保证不会错过秒杀活动。 频繁的访问程序

写在前面： 通知系统是网站信息传播机制的重要的一部分，足够写一大章来说明。本文只梳理设计原则，后续相关内容会持续更新。 这里的通知包括但不限于公告、提醒或消息（不同使用场景下的功能定义不同）。 关于各客户端平台（ios、android、wp等）的通知机制，在其交互设计指南中有更详细的说明，大家可自行参考。一、通知系统定义通知系统，顾名思义即通知信息的传达处理系统。目的是为了让用

0.Spring MVC配置文件中的配置 1.maven依赖 io.springfox springfox-swagger2 2.4.0 io.springfox springfox-swagger-ui 2.4.0 2.Swagger配置文件package com.jay.plat.con

本文旨在简单介绍大型互联网的架构和核心组件实现原理。 理论上讲，从安装配置，最佳实践以及源码来剖析各个组件，这个自然是极好的。由于笔者时间以及知识有限，有很多知识没有在工作中亲自实践的机会。所以有些地方语焉不详，还请大家多多指教。大型互联网架构解决问题的通用思路是将分而治之（divide-and-conquer），将大问题分为若干个小问题，各个击破。在大型互联网的架构实践中，无一不

本文主要描述在网站的不同的并发访问量级下，Mysql架构的演变,下面分别从不同的角度思考mysql的演变过程.可扩展性架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种Scale-up : 纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力Sc

大型网站架构演化特点：高并发、大流量高可用海量数据用户分布广泛、网络情况复杂安全环境恶劣需求快速变更、发布频繁渐进式开发演化发展历程0. 演变原因    在现有架构下，我们来看看数据存储的瓶颈是什么？     数据量的总大小  一个机器放不下数据的索引（B+ Tree）一个机器的内存放不下 访问量（读写混合）一个实例不

转自涛哥的博客：http://jinnianshilongnian.iteye.com/blog/22355721.构建亿级前端读服务从入职京东到现在，做读服务已经一年多的时间了，经历了各种亿级到百亿级的读服务；这段时间也进行了一些新的读服务架构尝试，从架构到代码的编写，各个环节都进行了反复尝试，压测并进行调优，希望得到一个自己满意的读服务架构。 一

来源：知乎 http://www.zhihu.com/question/22764869/answer/31277656首先推荐4本书大型分布式网站架构设计与实践http://item.jd.com/11529266.html大型网站技术架构：核心原理与案例分析http://item.jd.com/11322972.html大型网站系统与Java中间件实践

大规模流量的网站架构，从来都是慢慢“成长”而来。而这个过程中，会遇到很多问题，在不断解决问题的过程中，Web系统变得越来越大。并且，新的挑战又往往出现在旧的解决方案之上。希望这篇文章能够为技术人员提供一定的参考和帮助。 以下为原文当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这

首先看节点规划：        IP:192.168.0.99     Host:mgs02      Role：cobar        IP:192.168.0.101    Host:mysql01    Role：mysql-master1        IP:192.168.0.102    Host:mysql02    Role：mysql-slave1       

1.Spring实现数据库的读写分离现在大型的电子商务系统，在数据库层面大都采用读写分离技术，就是一个Master数据库，多个Slave数据库。Master库负责数据更新和实时数据查询，Slave库当然负责非实时数据查询。因为在实际的应用中，数据库都是读多写少（读取数据的频率高，更新数据的频率相对较少），而读取数据通常耗时比较长，占用数据库服务器的CPU较多，从而影响用户体验。我们通常

前不久，Java Code Geeks发表了一篇文章，分析单体应用与微服务的优缺点。近日，该网站又发表了一篇文章，提供了六种微服务架构的设计模式。聚合器微服务设计模式这是一种最常用也最简单的设计模式，如下图所示：聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业

XSS又称CSS，全称Cross SiteScript，跨站脚本攻击，是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。XSS攻击       

其实任何简单的问题，只要规模大了都会成为一个问题，就如中国人口多，很多小问题都会变成大问题一样。但处理这种海量数据的方法无非就是分治和”人海”战术。使用人海战术的前提是问题的划分能够支持这种人海战术，其手段无非是切割（纵向，横向）和负载均衡。纵向分隔主要是按业务（功能）来分，也就是所谓面向服务架构，横向分隔方式比较多，主要依赖于所处理的对象属性，比如时间属性或者特定业务数据属性划分（比如铁路客票的