非功能性要求

数据库的类型选择目前市场上数据库主要有关系型数据库Oracle,DB2,Mysql)NOSQL类型数据库(MogonDB)对象数据库(不是很了解)面向文档的数据库(apache couchBD),面向统计的数据库(HBASE)根据客票系统的类型应该是属于OLTP类型的系统但是考虑到商业上分析需求也属于OLAP型系统由于本次讨论OLTP系统的设计优先选择Oracle。为啥用的公司多市场上相关的技术工程师多DBA管理员多安全性和性能都不错。就是有点贵不过考虑到是铁道部完全忽略。对于部分客票系统非关键性业务也不重要的这一部分数据可以考虑使用Mysql。至于NOSQL没有用过这个主要是面向web2.0的对于事务要求高的系统不太适合。2 多数据中心在金融行业都必须部署多个数据中心避免在一个数据库机房故障之后全部数据都不可用。比如假如某地地震数据库所在机房宕机了如果这个时候检票或者买票就sb了所以需要尽快恢复。这样必须马上启动另外一个数据库机房配置。除去灾备情况考虑到铁路售票系统数据库的巨大访问量2011年的铁道部的旅客发送量---2011年全国铁路运输目标:旅客发送量19亿人次根据这个初略估计一下一年估计要20亿张票这个只是2011年的量按照未来的几年的增长按照目标值100亿人次估计相当于一天有2700W独立UV1亿PV。考虑到春节这个变态的高峰期瞬间的并发量比平时会高上千倍。如果只在一个数据库只有一台数据库就会存在单点一旦数据库挂掉了需要尽快的恢复。这个时候不太可能启用灾备数据库因为灾备是异地备份备份数据库同步数据比较慢网络延迟所以必须必须在同一个城市在部署一套数据库。这样在单点数据库故障的时候可以马上切到备份数据库。下面两幅图主要介绍异地灾备以及同城异机房备份的实现原理。同城备份数据一次写一份日志写两份。由于日志文件实时同步A服务器写完B服务器的日志文件B服务器马上就写自己的数据文件。这样不会丢失数据。当A服务器故障应用马上就可以切换到B服务器。不会存在单点故障。但是考虑特殊情况北京地震AB机房同时故障整个数据都丢失了。所以必须由异地灾备的数据中心。不过还有其他的方式这里就不做叙述了。总之是要做好去除单点。异地备份这个架构和同城备份有一点区别就是A服务器只会写A机房的日志文件然后A异步同步日志到B机房的日志文件。这里面会有几分钟的网络延迟。这里不实时写B机房的日志文件主要是性能。如果实时写B机房的数据一次更新操作就会至少有一次网络延迟上海到北京的网络传输时间。会影响数据库的性能。而同城市通过光纤连接传输速率快可以忽略网络延迟。如果A机房故障灾难性的故障比如地震机房被恐怖分析袭击就会丢失一部分数据丢失的数据就是网络延迟同步的数据。对于购票业务来说数据丢失几分钟的是可以接受的大不了我铁道部亏一点这几分钟丢失的数据我全部免票。也可以做一次好的营销。但是对于金融行业来说数据是不能丢失的这里的异地备份就不符合金融业的要求。用性能换取可用性。就像atm取钱一样一次交易涉及几分钟。你的交易数据银行至少会备份2份一份同城的一份异地的。3 硬件配置这一块不是很熟悉交给dba专业的人去做吧。小机 存储SAS。不过对于铁道部有钱上大机即可。不过我们还是按照互联网方式去分析设计系统使用普通的存储以及服务器。功能性分析1 业务流程分析先简单的了解一下购票系统的业务流程旅客到互联网也可能是其他渠道登录根据出发日期起始站终点站查询车票确定车次和座位预定车票然后进行支付支付成功之后发短信之后客户到线下去取票。一个简单的流程就结束了。从上面的流程可以看出整个业务流程中有几个以下几个实体以及实体的重要属性信息1 旅客信息假设都是实名的至少有三个重要信息 姓名身份证手机号2 车次信息车次起始站终点站类型发车时间到达时间3 车次停靠信息车次停靠站达到时间停靠时间4 余票信息车次起始站终点站发车日期剩余座票剩余卧铺。。。5 车票信息车次起始站终点站发车日期购票日期旅客姓名身份证手机号状态购票渠道支付日期6 支付信息金额支付日期支付银行支付金额支付方式7 短信信息车票信息验证码短信内容整个购票过程包括以上几个重要的实体其他的几个字段可以先不管。我们可以假设一下每一个实体的数据规模实体数据量日增量旅客信息上限-中国人口数 16亿这个真不好估计车次信息比较少假设10万日增应该也不会超过10车次停靠信息车次信息 ×200 200W日增应该也不会超过100车票信息巨大目前年增20亿未来年曾100亿自己换算一下不过不会很平均春节几天会暴增支付信息和车票信息同数量级和车票信息一样短信信息少于车票信息毕竟只有网络订票才会有短信线下购票不会有未知假设100W余票信息一年交易量 365×车次信息 5000W日增数据量 和 车次信息数量一致 假设10W从数据量来看 车票信息 支付信息 短信信息 余票信息 旅客信息 车次停靠信息 车次信息从如此数据量来看必须进行分库分表。所以分库分表就在设计库的时候就显的非常重要。2 简单分库策略旅客信息相关的信息单独分在一个库这些数据相对来说是读多写少并且可以大量进行缓存是基础相数据。车次相关的信息比如车次车次停靠可以单独放在一个标里面这个标是保存原数据信息数据量不大数据完全可以缓存。可以考虑和余票库放在一次。剩下就是四大的实体信息余票信息车票信息支付信息短信通知信息首先短信通知信息相对来说比较通用的可能未来很多业务都会涉及到短信通知所以短信相关的信息放在一个库在剩下就是考虑业务上比较耦合的三个实体余票车票支付。余票查询频繁没出一张票就会更新余票数车票数据量巨大有查询和更新需求支付信息单笔查询和更新需求