首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

有没有人,计划开源一套工业级“秒杀”系统架构?

想要搞透一套架构方案,最根本的方法,就是去实践它。 可是,大部分程序员,遇不到这样的业务,接触不到这样的场景啊,怎么办呢? 有个朋友自动化的搭了一套,能让所有人瞬间体验与调优高并发的秒杀架构,分享给大家! 对于秒杀类业务,系统上能如何优化呢? 方向上,主要有两点: 第一,将请求尽量拦截在系统上游,而不要让锁冲突落到数据库。 传统秒杀系统之所以挂,是因为请求都压到了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,访问流量大,下单成功的有效流量小。 第二,充分利用缓存。 秒杀买票,这是一个

01

数据库架构:主备+分库?主从+读写分离?

1、高可用分析:高可用,主库挂了,keepalive(只是一种工具)会自动切换到备库。这个过程对业务层是透明的,无需修改代码或配置。 2、高性能分析:读写都操作主库,很容易产生瓶颈。大部分互联网应用读多写少,读会先成为瓶颈,进而影响写性能。另外,备库只是单纯的备份,资源利用率50%,这点方案二可解决。 3、一致性分析:读写都操作主库,不存在数据一致性问题。 4、扩展性分析:无法通过加从库来扩展读性能,进而提高整体性能。 5、可落地分析:两点影响落地使用。第一,性能一般,这点可以通过建立高效的索引和引入缓存来增加读性能,进而提高性能。这也是通用的方案。第二,扩展性差,这点可以通过分库分表来扩展。

02

什么是n-tier(层)架构理论?什么是BO,DO,PO,VO,DTO,BoDto,DoDto?

马克-to-win:在 软件公司工作的一个常态就是需求经常变动。这是迭代开发的一个主要特征。为了节约成本和生存问题,软件公司一般都采取迭代开发的模式。三个星期为一个周 期,推出一个版本,给客户看。客户提出一堆意见,产品经理根据客户意见和市场竞品分析和自己公司总经理意见及各路考量,再出一版产品需求,之后逼着技术部 门以火箭一般的速度,完成他的需求。马克-to-win:作为技术负责人的我,深知他的需求今天是朝东,明天可能就是朝南,后天也许还朝西,没办法 ,都是客户需要的,领导需要的和市场需要的,还得去干。不但得干,而且还得以最快的速度干。这里看出来没有,就是两点。 一,不断要去改。二来还得快。结论就是必须要用n-tier(层)模式开发。这样我就可以把分工分得很细。需要改动时,可以一步到位,找到需要改动的地 方,而且还可以非常快。刚才其实提了一点n-tier架构,把model细化分成了几层。现在继续把其中的服务层(service)细化,变成 service层调用BO(Business Object)层,BO层调用DO(domain object)层。马克-to-win:这里首先说为什么叫层?比如说:DO层里包含了很多的DO,而不是一个。什么是DO?DO是domain object,又叫领域对象。就是数据库中每个有现实意义的表都对应一个DO。比如多对多关系表在现实就没有意义 (TeacherStudentRelation),DO有自己的业务方法。BO (Business Object)就是现实中个别一个复杂对象或一堆有密切关系的DO对象所代表的抽象无形的有现实意义的概念对象。比如“手”和“ 脚”数据库中有实体表,所以“手”和“脚”都是DO。而“四肢 ”只是概念,没有表对应,是BO。BO也有业务方法。service当中可能有些发Email的方法,或安全编码的方法,这些不涉及数据库,和BO不同 (BO涉及数据库)。当涉及到“手脚并用”时,就调用“四肢”这个BO当中的方法。这个方法当中涉及到“脚”的方法时,就调用“脚”这个DO的方法。 “脚”这个DO里的业务方法涉及到数据库时,就调用Dao中的方法。

04
领券