资源预览内容
第1页 / 共57页
第2页 / 共57页
第3页 / 共57页
第4页 / 共57页
第5页 / 共57页
第6页 / 共57页
第7页 / 共57页
第8页 / 共57页
第9页 / 共57页
第10页 / 共57页
亲,该文档总共57页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
1、酒店预订怎么实现 ?怎么设计表 你好,我大概的说下我们的业务流程,我们的业务流程是:用户在网站浏览酒店信息,可以根据地区检索出该地区的酒店信息。列表展示酒店的信息由:酒店的名称,酒店图片,酒店位置,评论人数,评论分数以及最低入住价格。用户选中要入住的酒店进入酒店详情页面,查看酒店的介绍以及酒店的房型列表,用户根据他要入住的时间和离店的时间,检索出这个时间段内的所有可选房型(房间数量-当天的订单-当天未离店订单=剩余房间数量)显示给用户。用户选择好房型后就可以进行下单,要求有订单的开始时间,结束时间,房间数量,住客姓名,抵店时间,联系方式,备注信息等等。 那我的表是这么设计的,总共有6张表,分别是:用户表user,里面有下面几个字段,(用户编号,用户名称,用户密码,用户联系方式)酒店表hotel,里面有(酒店编号,酒店名称,酒店图片,评论人数,评论分数,最低入住价格,所在地区)酒店图片表pic(图片编号,图片地址,图片排序,图片所属酒店)评论表comment(评论编号,评论内容,评论时间,用户编号,酒店编号)房型表house(房型编号,床型,早餐,宽带,人数上限,房价,房间数量,最长预定时间)订单表order(订单编号,开始时间,结束时间,房间数量,住客姓名,最晚抵店时间,联系电话,使用优惠券,备注,订单状态)以上就是我对这个酒店预订系统的设计2、预定时间怎么写入数据库的以预订当时的时间戳作为预订时间写入数据库。用户下订单时会选择一个抵店时间,将该抵店时间以时间戳方式存入数据库中。离店时间以当时的日期转为时间戳方式存入数据库中3、怎么判断还有没有房间我可以根据用户的入住时间和离店时间来检索这个有效时间段内房间的库存。房间数量扣除在这个时间段内入住的订单和在这个时间段内离店的订单。扣除后等到的数量才是这段时间内有效房间数量。4、怎么记录每天的房间库存我的思路是根据一个公式来推理实现的,每天房间的库存=房型下房间数量-(当天入住的订单+当天未离店的订单),这样我就可以得到每天还有多少房间是剩余的了。5、怎么在数据库里对房间做唯一标识上面所设计的房型表就是我们的房间表,每个房间是唯一的,我们是使用数字作为编号的,也即使用主键作为唯一标识。6、最近出的新功能 最近我们出了个会员机制,客户第一次预订酒店成功后,可以办理会员卡,凭借会员卡,下次来的时候可以打折,会员在一些比较特殊的日期预订酒店成功,可以享受不一样的优惠措施。7、 怎么保证促销商品不会超卖 这个问题是我们当时开发时遇到的一个难点,超卖的原因主要是下的订单的数目和我们要促销的商品的数目不一致导致的,每次总是订单的数比我们的促销商品的数目要多,当时我们的小组讨论了好久,给出了好几个方案来实现:第一种方案是:在每次下订单前我们判断促销商品的数量够不够,不够不允许下订单,更改库存量时加上一个条件,只更改商品库存大于0的商品的库存,当时我们使用ab进行压力测试,当并发超过500,访问量超过2000时,还是会出现超卖现象。所以被我们否定了。第二种方案是:使用mysql的事务加排他锁来解决,首先我们选择数据库的存储引擎为innoDB,使用的是排他锁实现的,刚开始的时候我们测试了下共享锁,发现还是会出现超卖的现象。有个问题是,当我们进行高并发测试时,对数据库的性能影响很大,导致数据库的压力很大,最终也被我们否定了。第三种方案是:使用文件锁实现。当用户抢到一件促销商品后先触发文件锁,防止其他用户进入,该用户抢到促销品后再解开文件锁,放其他用户进行操作。这样可以解决超卖的问题,但是会导致文件得I/O开销很大。最后我们使用了redis的队列来实现。将要促销的商品数量以队列的方式存入redis中,每当用户抢到一件促销商品则从队列中删除一个数据,确保商品不会超卖。这个操作起来很方便,而且效率极高,最终我们采取这种方式来实现8、redis集群怎么做1、 Redis集群提供了以下两个好处1、将数据自动切分(split)到多个节点2、当集群中的某一个节点故障时,redis还可以继续处理客户端的请求。2、集群的方案: redis-cluster集群,采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接,主要通过节点的配置,辅以redis的主从来完成集群。由于这块东西我使用得很少,所以只是平时抽时间去研究过,并没有真正的在线上实现过。9、redis和memcacahe、mongoDB的区别答:都是非关系型数据库,性能都非常高,但是mongoDB和memcache、redis是不同的两种类型。后两者主要用于数据的缓存,前者主要用在查询和储存大数据方面,是最接近数据库的文档型的非关系数据库。 这里我主要谈谈memcache和redis的区别。从数据存储位置上来分,memcache的数据存在内存中,而redis既可以存储在内存中,也可以存储的到磁盘中,达到持久化存储的功能,memcache一旦断电,数据全部丢失,redis可以利用快照和AOF把数据存到磁盘中,当恢复时又从磁盘中读取到内存中,当物理内存使用完毕后,可以把数据写入到磁盘中。 从存储数据的类型上来分,memcache和redis存储的方式都是键值对,只不过redis值的类型比较丰富,有string(字符串),hash(哈希),list(列表),set(集合)zset(有序集合),而memcache主要存储的是字符串。 从架构层次来分,Redis支持master-slave(主从)模式应用,memcache支持分布式。 另外从存储数据的大小上来分,Redis单个value的最大限制是1GB,memcached只能保存1MB的数据。但是Memcache在存储100K以上的数据,性能稍微好一点。 另外redis只支持单核,memcache可以支持多核,当然关于redis取代memcache的说法,在一般情况下,两者性能都很高,在大多的业务场景选择上,redis的选择可能更加具有优势,但也不能说可以完全取代,最终还是取决于你的应用场景。10、持久化redis有几种方式?答:主要有两种方式: 快照持久化在redis配置文件中已经自动开启了,格式是:save N M表示在N秒之内,redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave(异步)命令来做快照append only file AOF持久化 总共有三种模式,如appendfsync everysec默认的是每秒强制写入磁盘一次 appendfsync always 每次执行写操作的时候就强制写入磁盘appendfsync no 完全取决于os,性能最好但是持久化没法保证其中第三种模式最好。redis默认的也是采取第三种模式。11、mysql存储引擎答:常用的主要分为两种,一种是innodb,一种是myisam,两者的主要区别是myisam不支持事务处理,而innoDB支持事务处理myisam 不支持外键,innoDB支持外键myisam支持全文检索,而innoDB在MySQL5.6版本之后才支持全文检索数据的存储形式不一样,mysiam表存放在三个文件:结构、索引、数据,innoDB存储把结构存储为一个文件,索引和数据存储为一个文件myisam在查询和增加数据性能更优于innoDB,innoDB在批量删除方面性能较高。myisam支持表锁,而innoDB支持行锁12、 sql注入是什么及如何预防sql注入?答:SQL注入攻击指的是用户或者黑客通过构建特殊的输入作为参数传入我们的Web应用程序端,而这些输入大都是SQL语法里的一些组合,通过执行SQL语句进而执行攻击者所要的操作,其主要原因是程序员没有细致地过滤用户输入的数据,致使非法数据侵入系统而造成的。因此我们在做开发过程中一定要预防sql注入,主要从两方面着手:1、占位符的方式,就是对sql语句进行预处理,然后执行sql语句2、通过addslashes或者mysql_real_escape_string这两个函数对用户输入的值进行转义处理,把一些特殊的字符转义掉。13、有用过预处理么?答:用过,PDO类中,有个prepare方法可以实现预处理,PDOStament类中的excute方法可以执行预处理,预处理的参数分为两种,一种是:字符串占位符,另一种是?占位符,:字符串占位符在执行预处理传递参数时传入的是关联数组,而?占位符传递的是索引数组。两者不能混合使用,但一般推荐使用:字符串占位符。14、用框架还用自己的处理吗答:一般成熟的开源框架中都考虑到了数据安全这方面的东西,但有时候我们可能会使用一些原生的SQL语句时,我们就需要考虑自己对sql语句进行预处理。当然有时候框架中的过滤方法我们不希望采用,比如使用文本编辑器时,我们可以使用自己的过滤方式。15、mysql优化怎么做的?答:mysql优化主要从以下几个方面来实现: 设计角度:存储引擎的选择,字段类型选择,范式 功能角度:可以利用mysql自身的特性,如索引,查询缓存,碎片整理,分区、分表等 sql语句的优化方面:尽量简化查询语句,能查询字段少就尽量少查询字段,优化分页语句、分组语句等。 部署大负载架构体系:数据库服务器单独出来,负载大时可以采用主从复制,读写分离机制进行设计 从硬件上升级数据库服务器。16、订单表用是什么存储引擎答:因为订单表存在着事务的处理,比如下了订单,商品的库存就要减少,这里就涉及到了事务,所以就用到innodb19 、sql语句的优化答:首先我们得确定哪些sql语句需要优化,一般在一个系统中,查询语句最多,所以我们主要是针对查询语句进行优化。主要采用两种方式来确定要优化的sql语句: 使用慢查询日志,设置需要优化的sql语句的执行时间,记录下超过该设置时间的语句,即为需要优化的语句。 使用profiling机制,记录下每条sql语句的执行时间,找出执行较慢的语句,即为需要优化的语句。 我们主要通过给表字段添加索引的方式进行优化,加上索引后,sql语句的执行时间显著提高了,但并不是加上索引了这条sql语句就会用到索引,所以首先看执行慢的语句后面是否有加索引,我们可以使用explain或者desc加在要执行的sql语句前,查看是否使用到索引。有几个地方需要注意的是: 为了避免建议索引而造成索引文件过大,有时候我们会使用复合索引,这时候要遵循最左原则。 like查询,前%不会用到索引 如果条件中有or,则要求or的索引字段都必须有索引,否则不能用到索引。 如果列类型是字符串,一定要在条件中将数据使用引号引用起来,否则不使用索引。 优化group by 语句 尽量避免模糊匹配,这样会导致全盘扫描21、 索引有几种欧4答:索引主要有: 主键索引:数据记录里面不能有null,数据内容不能重复,在一张表里面不能有多个主键索引。 普通索引:使用字段关键字建立的索引,主要是提高查询速度 唯一索引:字段数据是唯一的,数据内容里面能否为null,在一张表里面,是可以添加多个唯一索引。 全文索引:在比较老的版本中,只有myisam引擎支持全文索引,在innodb5.6后引擎也支持全文索引,在mysql中全文索引不支持中文。我们一般使用sphinx集合coreseek来实现中文的全文索引。复合索引23 、左前索引原则答:左前索引主要指的是在复合索引中,给两个或多个字段建
收藏 下载该资源
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号