fyxxq的专栏

又拍网是一个照片分享社区，从2005年6月至今积累了260万用户，1.1亿张照片，目前的日访问量为200多万。5年的发展历程里经历过许多起伏，也积累了一些经验，在这篇文章里，我要介绍一些我们在技术上的积累。又拍网和大多数Web2.0站点一样，构建于大量开源软件之上，包括MySQL、PHP、nginx、Python、memcached、redis、Solr、Hadoop和RabbitMQ等等

分布式消息系统 RocketMQ 分布式事务

分布式事务 阿里云GTS

总结一下Redis的特性以及Redis分布式的相关知识1. 单线程2. 支持对象类型丰富StringHash：key对应一个hashmap，类似于Bean的存储ListSetSorted setpub/sub：发布于订阅，适用于实时消息系统Transactions：不完全的事务，但在大多数正常情况下，可以保证一连串的命令是顺序在一起执行的（提供了一个Watch功能，你可以对

分布式系统越做越大，服服务化规模也越来越复杂，为了减轻运维压力、提高排错能力，分布式系统的全链路监控系统就显得尤为重要了。监控系统通常会包括几个部分：第一， 数据埋点和采集 ，这个相当重要，其实说白了，数据是整个监控系统最核心的部分，必须有能力快速和正确和方便地采集日志，所以我们在数据埋点和采集上做了很多文章。第二， 指标计算 。指标计算有好几种方式，一种我可以在客户端做一些计算，

最近遇到这两个问题，整理思路如下。应对雪崩通过流控，然后对每秒请求数量的限制，或者线程并发的限制。让系统不雪崩。或者说通过实时的监控平台，发现雪崩的正在形成。然后实时调整参数，避免雪崩。某个业务大概有多少的量其实一般都是比较清楚的，不会超过太多，设置时增加一点的量，给一个数值给它，如果超了，或者达到的报警值，那么就可以查下原因，是真的业务增长了还是的系统出了问题。另外，及时识别和处

common issue:一致性hash分布式系统间的通讯，复杂性，延迟性。调试/跟踪 困难。对每个系统的日志，监控及检测。分布式数据库（主从）数据库同步问题----solution:缓存数据与数据库更新的 相互通知 ---solution: 事件驱动。interview 1:memcached的使用session共享业务操作时(将一个变化

spring JTA对于A这边，timeout的事务，A系统会做记录，然后轮询B系统，是否那边也是失败的，如果是失败的。则不管，若是成功的，则通知管理员，手动把A系统对应的状态，改回来

1. session的复制与共享在web应用中，为了应对大规模访问,必须实现应用的集群部署.要实现集群部署主要需要实现session共享机制,使得多台应用服务器之间会话统一, tomcat等多数主流web服务器都采用了session复制以及实现session的共享. 但问题还是很明显的：在节点持续增多的情况下,session复制带来的性能损失会快速增加.特别是当session中保存了较

Zookeeper的几个核心术语：Znode, Watcher，ZK事件通知的延时，Leader Election：也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点，不同的是它还是一个 SEQUENTIAL 目录节点，所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_

对于移动互联网应用，他所涉及到的架构难点和传统互联网有些不一样。比如，Instagram的架构：http://blog.sina.com.cn/s/blog_56c9b55c0101195u.html 以及 http://www.poluoluo.com/jzxy/201105/134258.html简单的总结就是，移动应用的整体架构，主要考虑以下几个方面：1. 消息推送: andro

1 今年春节期间铁路客流量据说有31亿2 目前12306 pv是14亿，而高峰期就在8点到10点，那么也就是有可能在这两个小时里有5亿访问量，而每秒的并发量估计在最高峰时能达到几千万3 目前Ngix能处理在线1万，但是实际值一般是8000左右4 一台IBM大型机要几千万美元，估计加上DB2，交易中间件，得小1亿了5 腾讯，淘宝等拥有总在线人数4亿规模或者事务处理达到亿级别的规模耗时

分库分表的经验：第一原则：能不切分尽量不要切分。 第二原则：如果要切分一定要选择合适的切分规则，提前规划好。 第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库 Join 的可能。 第四原则：由于数据库中间件对数据 Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表 Join。常用框架cobar，mycat，sharding-jdb...