南宁网站建设 超博网络,刚发布的手机,wordpress 主题演示文件 导入,网站开发管理工具有哪些一、学习动机 伴随互联网行业的兴起#xff0c;越来越多的领域需要相应的技术方案#xff0c;比如#xff1a;打出软件、电商平台、直播平台、电子支付、媒体社交。 身边常见的#xff0c;校园出成绩那一年#xff0c;我们会感觉网站异常的卡顿#xff0c;因为访问人数太… 一、学习动机 伴随互联网行业的兴起越来越多的领域需要相应的技术方案比如打出软件、电商平台、直播平台、电子支付、媒体社交。 身边常见的校园出成绩那一年我们会感觉网站异常的卡顿因为访问人数太多。 单机单点的数据库一旦这台机子宕机(机器出现故障、机房停电、...)那整个网站将无法正常访问。这时候集群就出现了一台机器出现问题了另外的机器还在正常运行网站依旧可以访问。 集群案例滴滴出行、淘宝、京东、斗鱼直播、支付宝、微信、QQ 二、案例 1.天猫双十一 2017年天猫双十一的交易额达到1682亿元3分钟破百亿9小时破千亿 交易峰值(下订单的峰值)32.5万/秒 支付峰值25.6万/秒 数据库峰值4200万/秒 支持这么漂亮的数字完美运行除了数据库集群技术还有云服务器、负载均衡、RDS云数据库等技术 2.微信红包 2017年除夕当天全国人民总共收发142亿个红包峰值42万/秒 央视春晚微信摇一摇互动总量达110万亿次峰值8.1亿/秒 三、学习目标和方式 1.学习目标 1向大型互联网应用看起学习架构设计和业务处理 2掌握PXC集群MySQL方案的原理 3掌握PXC集群的强一致性 4掌握PXC集群的高可用方案 2.学习方式由浅入深循序渐进案例有小到大逐步扩展 四、硬件环境需求 1.win10 x64专业版或者企业版PXC不支持windows需要用到虚拟机所以最好不要使用home版或者32位的系统/Linux/MacOS 2.Docker虚拟机 3.内存8GB以上 五、单节点数据库的弊端 1.大型互联网程序用户群里庞大所以架构必须要特殊设计 2.单节点的数据库无法满足性能上的要求就像校园网查成绩的时候如果1万人同时查你可能拿到就是一个白屏无论你是收费的还是免费的数据库单节点都满足不了这种并发需求 3.单节点的数据库没有冗余设计无法满足高可用一旦这个机器出现问题没有其他节点的数据库顶替那网站将无法正常访问 单节点数据库测试5000个连接5000个并发查询平均就1个连接1个查询安装好数据库配置好环境变量[mysqld]下面配置最大连接量为6000max_connections6000执行下面的命令 mysqlslap -hlocalhost -uroot -pabc123456 -P3306 --concurrency5000 --iterations1 --auto-generate-sql --auto-generate-sql-load-typemixed --auto-generate-sql-add-autoincrement --engineinnodb --number-of-queries5000 得到下面的结论 这才5000个并发需要的时间就达到了34秒如果设置10000个并发将如何呢 数据库拒绝了很多请求把没有拒绝的执行了需要的时间是167秒这就是单击单点在面对并发的时候数据库的承受能力。 六、PXC高可用集群方案 这样一个最基本的PXC集群它保证了每个节点的的数据都是一致的不会出现数据写入了数据库1而没有写入数据库2的情况这种的集群在遇到单表数据量超过2000万的时候mysql性能会受损所以一个集群还不够我们需要把数据分到另一个集群这个称为“切片”就是把大量的数据拆分到不同的集群中每个集群的数据都是不一样的看下面的截图 这样一来PXC集群1存前面1000万条数据PXC集群2存后面1000万条数据当一个sql语句请求的时候通过MyCat这个阿里巴巴的开源中间件可以把sql分到不同的集群里面去。这种的分片按照数量就是2个分片。 这个切分算法也比较多比如按照日期、月份、年份、某一列的固定值或者最简单的按照主键值切分主键对2求模余0的存分片1余1的存分片2这样MyCat就会把2000万条数据均匀地分配到2个集群上。 PXC虽然保证了数据的强一致性但是这是以牺牲性能为代价的所以适合保存重要的数据比如订单。 七、Replication集群方案 这种集群在第一个节点插入以后就马上返回给客户端执行成功了然后再做每个节点之间的同步如果某一个同步操作失败了那用户请求的时候拿到的数据就不同步了但是它的优势是速度快不会牺牲任何地性能适合保存不那么重要的数据比如日志。 八、PXC与Replication集群结合 九、系统架构方案 更加清晰和详细架构请看下面的截图 十、APP的架构设计 客户端包括web浏览器端移动手机端用户通过客户端发送一个请求后Nginx接收到请求后会做负载均衡定向到当前最适合相对没那么繁忙处理这个请求的服务器端服务端接收到请求后再访问数据库一些热点数据需要做缓存比如淘宝首页的商品。从上面的图中看服务器端的某一个出现故障后nginx会将请求定向到剩下的能正常运行的服务器上面而数据库端也是采用的集群这样就达到了高可用就是任意一台机器出现故障对整个网站的运行不会产生太大的影响这里可能有人会问如果nginx这台服务器出现问题了怎么办可以做虚拟ipvip,配置主从入口就是nginx1和nginx2的虚拟ip是一样的其中有一个是主入口在主入口没有出现问题的时候从机是不会工作的当主入口机出现问题了从入口机就会顶替如果主从都出现问题了那网站将无法访问。 服务器端的spring与spring之间的调用又是如何的现在都是分布式调用比较经典的是dubbozookeeper。这里有同步调用和异步调用 同步调用提出问题的一方直接调用处理问题的一方 异步调用提出问题的一方将问题交个消息中间件由消息中间件去将问题发放给处理问题的一方在这里提出问题的一方称为“生产者”处理问题的一方称为“消费者”他们彼此是不知道对方是谁达到业务解耦的效果这样做的好处是以后在部署项目、程序的升级、接口的变更的时候它的影响面就很小。比如说生产者项目开发地有问题然后用其他语言再做了一个项目对消费者不会产生任何影响只要生产生能正常往消息队列里面发送消息就好再比如用户注册一个淘宝账号我们连带着把支付宝账号也给你开通然后其他的投资的项目也给用户一些优惠给你2张淘票票的电影票免费一个月的虾米音乐会员等等对应淘宝这一端它发起一个消息传达给消息队列至于接收端是支付宝还是淘票票还是虾米音乐淘宝这一端不知道也不需要关心等以后阿里再有什么投资项目需要给新用户优惠的时候只需要从消息队列里接收消息就可以对生产者而言没有任何影响。如果是同步调用dubbo或者webservice调用其中一端有修改另一端必然也要改这种强耦合是不好的。 以下是异步调用方案图 转载于:https://www.cnblogs.com/xyabk/p/10906952.html
