网站做前端,把网站扒下来以后怎么做,东莞网站建设业务的公司,移动做网站吗基本功能 LAMP#xff08;LinuxApacheMySQLPHP#xff09;标准架构#xff0c;初期采用拿来主义#xff0c;只具备基本功能。
数据库#xff1a;读写分离#xff0c;MyISAM存储引擎
2003年5月—2004年1月
存储瓶颈
mysql达到访问瓶颈#xff0c;升级成oracle#x…基本功能 LAMPLinuxApacheMySQLPHP标准架构初期采用拿来主义只具备基本功能。
数据库读写分离MyISAM存储引擎
2003年5月—2004年1月
存储瓶颈
mysql达到访问瓶颈升级成oracle从开源转向商用。
oracle是连接池php是短连接直连会导致内存打满引入SQL Relay连接池。
2004年1月—2004年5月
连接瓶颈
SQL Relay的问题无法处理而Oracle又无可替代只能替换掉php语言改用java MVC框架是阿里的WebX控制层用了EJB持久层是ibatis。 另外为了缓解数据库的压力商品查询和店铺查询放在搜索引 擎中。
2004年2月—2005年3月
查询瓶颈 数据库分库分表、放弃EJB、引入Spring、加入缓存、加入CDN
2004年10月—2007年1月
存储瓶颈
多而小的海量图片存储查询问题自研符合淘宝特性的海量文件存储系统用于存储图片。
借鉴 GFSGoogle File System开发出TFSTaoBao File System 典型的一主多从架构主保存元数据进行索引从进行存储以block为基础单元。 域名-》DNS-》LVS-》nginxkong的分布式特性可以代替LVSnginx
前端有LVSHaproxy将原图和其所有的缩略图请求都调度到同一台Image Server
在文件定位上内存用Hash算法做索引最多一次读盘。另外会有很多相同的图片重复上传上来去除重复文件也是采用Hash算法来做的。写盘方式则采用Append方式写并采用了淘汰策略FIFO主要考虑降低硬盘的写操作没有必要进一步提高Cache命中率因为ImageServer和TFS位于同一个数据中心读盘效率还是非常高的。
在创造了TFS和Tair之后整个系统的架构如下图所示 架构之美
一个好的架构一定是可扩展和稳定目前业内的通用办法是解耦也就是拆分成微服务。 UIC用户中心User Information CenterTC交易中心Trade CenterIC商品中心Item CenterSC店铺中心Shop Center
这些中心级别的服务只提供原子级的业务逻辑如根据ID查找商品、创建交易、减少库存等操作。再往上一层是业务系统TMTrade Manager交易业务、IMItemManager商品业务、SMShop Manager后来改名叫SS即Shop System店铺业务、Detail商品详情。
拆分之后系统之间的交互关系变得非常复杂 拆分的优点无非就是解耦的优点但拆分必然伴随着三个问题
实时调用的中间件淘宝的HSF高性能服务框架异步消息通知的中间件淘宝的Notifysession共享共享状态信息
涉及到的技术
集群大家做一样的事情分布式大家做不一样的事情负载均衡工作量相当动态调控动态增减资源
HSF nacosdubbo解决服务间的调用RPC调用
Notify 异步通知MQ/Kafka
TDDL
分库分表Taobao Distributed Data layer之前一直以为很简单那是因为没有想实际使用需要解决的问题只想到一个 hash取模存储问题其它问题一概没想
如何实现分布式Join连接——在跨节点以后简单的Join会变成M×N台机器的合并这个代价比原来的基于数据库的单机Join大太多了。如何实现高速多维度查询——就像SNS中的消息系统A发给B一个消息那么A要看到的是我发给所有人的消息而B要看到的是所有人发给我的消息。这种多维度查询如何能够做到高效快捷呢如何实现分布式事务——原始单机数据库中存在着大量的事务操作在分布式以后分布式事务的代价远远大于单机事务那么这个矛盾也变得非常明显。
目前业内的解决办法
利用uid进行shardingKey此时uid相关的查询会本地join分布式join部分在内存进行聚合。内存聚合二阶段提交分布式事务业内很多解决办法
Sesssion
若是分布式则只能放到公共池中存储例如redis若是集群则可以考虑分流保证同一个session的请求始终进入同一个服务
