无故障要求

一般可用指标能达到 99.999% 的系统就很牛逼了，一年的故障时间大概是 5 分钟 楼主你这个问题太宽泛了，没有实际的意义，最好能说一下你的需求

很类似给10086 发短信查信息这样的平台，不能让用户等太久，基本算是1分钟延时。 什么时候他都有可能会发短信查询。 【 在 coolfantasy 的大作中提到: 】 : 一般可用指标能达到 99.999% 的系统就很牛逼了，一年的故障时间大概是 5 分钟 : 楼主你这个问题太宽泛了，没有实际的意义，最好能说一下你的需求 : -- : ...................

时延跟故障又是两个概念了 时延与系统的吞吐量相关，具体到某个业务系统这就是非常细节的问题了，需要有一个非常系统的方案来保证低延时高可用，不同业务之间的差别也是很大的 10086 这样的例子对于学生来说还是太遥远了，建议结合实际项目来考虑这个问题，任何脱离实际需求的设计都是无意义的 【 在 crazyhadoop 的大作中提到: 】 : 很类似给10086 发短信查信息这样的平台，不能让用户等太久，基本算是1分钟延时。 : 什么时候他都有可能会发短信查询。

现在老师给的需求也差不多，mysql每天要增加约50万条记录，然后，用户以短信的模式去查询。查询是越来越慢了，系统一天基本要down一次了。谈不上7*24小时了。 【 在 coolfantasy 的大作中提到: 】 : 时延跟故障又是两个概念了 : 时延与系统的吞吐量相关，具体到某个业务系统这就是非常细节的问题了，需要有一个非常系统的方案来保证低延时高可用，不同业务之间的差别也是很大的 : 10086 这样的例子对于学生来说还是太遥远了，建议结合实际项目来考虑这个问题，任何脱离实际需求的设计都是无意义的 : ...................

要提升性能的话，把表分区吧 我们的一个项目，每天会产生几千万的话单，表分区以后，查询的效率还是很高的，不过我们那个项目用的是oracle 还可以考虑缓存，memcache，redis之类的来减轻数据库查询的压力 【 在 crazyhadoop (crazyhadoop) 的大作中提到: 】 : 现在老师给的需求也差不多，mysql每天要增加约50万条记录，然后，用户以短信的模式去查询。查询是越来越慢了，系统一天基本要down一次了。谈不上7*24小时了。

噢。这个分区按照手机号分段吗？ 容错采用啥机制？ 【 在 ox 的大作中提到: 】 : 要提升性能的话，把表分区吧 : 我们的一个项目，每天会产生几千万的话单，表分区以后，查询的效率还是很高的，不过我们那个项目用的是oracle : 还可以考虑缓存，memcache，redis之类的来减轻数据库查询的压力 : ...................

我们的分区是根据时间分的，再针对查询条件做了索引 【 在 crazyhadoop (crazyhadoop) 的大作中提到: 】 : 噢。这个分区按照手机号分段吗？ : 容错采用啥机制？

每天只有 50w 条记录那问题就简单很多了，先分析一下系统的性能瓶颈在哪里

嗯，是在查询那里读取，特别慢，原来有大概有3亿3千万条，最崩溃的是有个很简单的select 读了7个小时才读出来，貌似是硬盘io不给力。现在换了机器，32G内存，4核。 现在有10个分mysql 大概每个每天50万（初步估计）条记录加入。个别某些记录可能会和库中数据重复。还要处理一下， 这个插入实在是有点忍受不来了。打算分表试试。 【 在 coolfantasy 的大作中提到: 】 : 每天只有 50w 条记录那问题就简单很多了，先分析一下系统的性能瓶颈在哪里 : --