由12306谈网站性能技术

Plus de détails

监控系统2012年规划-readonly

par west source

nowcart-关键链路图

par Zhang Zhixiang

产量计算

par Yituo Lin

ARMS,押品系统目前问题

par 诗君朱

一种设计方式

查询

静态内容放缓存

车次-时间表（key-value）可用redis

架构图

小结

使用云计算

修改业务形态

像机票一样提前预定，还有优惠什么的

eg:不是早上八点放票

各省市建分站

每种技术都有复杂性，设计要做权衡

系统必须能“水平扩展”

方便：加三十倍服务器

后端优化

异步、节流阀、批处理

批处理

节省带宽

相同请求批量处理

节流阀 throttle

防止系统被超流量搞垮

不提升性能

技术上

技术问题

4.消息机制

消息乱序

消息丢失

3.多线程多进程，并发控制麻烦

2.程序回滚复杂

1.被调用方结果返回，涉及进程间通信的问题

处理程序做成并行，课水平扩展

业务上

收集请求

后端系统负载均衡

功能

健康各服务器负载

内存换页

并发

内存

CPU

分配任务

任务队列

需要考虑持久化

可以批量把任务分配给处理器

抢占式（拉）

下游服务器拿任务，简化系统复杂度

源头

路由器是均衡流量的，流量不代表服务器繁忙程度

数据分区不能减轻热销商品的负载

数据分区

4.同一数据分区

10000库存=>10台*1000库存

3.平均分表

eg:主键ID范围

第一种方式不一定平均

2.字段分类

不常改的数据放到一个表里，常改的放到多个表里

减少字段数量

竖着分表

1.逻辑分类

车型

铁路局

线路

一张表拆成多张一样字段但不同类的表

数据镜像不能解决表里记录太多的问题

数据镜像

高可用性->一台废了，还有其他可以

保证一致性

负载均衡

主流数据库都支持replication

数据冗余

NoSQL快，但不容易变回关系型

牺牲一致性

减少表连接

前端优化

计算量推给浏览器

前后日期提前查询

eg:select where x=a 和 select where x=a-1 or x=a or x=a+1都可以

读写分开

写

真正买再写数据

读

local cache

memcache

缓存的问题

重建与持久化

换存越大，重建越慢

系统维护会造成缓存丢失

换页

和操作系统的内存换页和交换内存相似

LFU

LRU

FIFO

内存可能不够，需要把不活跃的换出内存

更新

2.后端通知更新

实时性好

复杂

1.time out 重查

实时性差

简单

与数据库同步

诸多NoSQL都支持以下三大问题

优化查询

余票查询

不显示余票数量

显示有没有

用反向代理合并相同的并发查询

每个查询做hash,可用nosql计划实现

查询结果缓存

前端页面静态化

nginx的sendfile功能让静态文件直接在内核心态交换，增加性能

gzip

静态化不常变的页面和数据

减少网页大小，增加带宽

问题

一次浏览后浏览器缓存很多，只有10k

12306首页900k

减少前端链接数

方法

图标一个文件

CSS一个文件

把JS打成一个文件

用CSS分块展示

一个登陆查询页面

隐患

TCP链接后端不会立刻释放

用户会多页面访问

12306

一次访问后浏览器会有cache，但依然很多

车票预订70个HTTP

主页60个HTTP连接

前端负载均衡

DNS负载均衡器

最后有CDN

因为http请求是短作业，所以简单的负载均衡

在路由器上根据路由的负载重定向

业务

业务难度

难：下单负载

异步

中：查询负载

缓存

易：浏览网页高负载

电商

一致性

B2C异步

不成功有确认邮件

延时处理

传统加锁

库存操作

3.扣除库存

2.支付（可选）

1.占据库存

库存

库存更新

库存查询、计算

B2C噩梦

查询操作

奥运门票

不需要保证数据一致性，没有锁，容易水平扩展

事后抽奖

秒杀

停止秒杀后批量写数据库

内存里cache放可秒杀的数量，分布式放，100商品，10台*10个

不操作后段数据，只对下单log

只接受前N个请求

问题角度

锁

只要有锁，性能一定上不去

均衡

服务器，后端

一致性哈希

流量，前端

路由器

问题出错

HTTP500之类的错误

后端服务器垮了

没有响应

带宽问题

动态

数据一致性是最大问题

十万是遥不可及的