week4 - 作业



题目

一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？请列举描述。

作业

CDN

作用：提高静态资源访问速度



硬件负载

硬件负载通常都是商业产品

作用

提供负载均衡，分流请求，减少单机负载压力

解决方案

F5 贵，性能最好

A10 高性能，主要是性价比高

注：云服务可以不考虑硬件负载



软件负载

作用

提供负载均衡，分流给集群节点，减少单机负载压力

技术方案

常用中间件：LVS、HAProxy、Nginx

性能：LVS > HAProxy > Nginx

可组合使用



容器

作用

规范化部署，更容易支持扩容，对微服务友好



技术方案

docker：早期容器技术，提供docker-compose也具有编排能力

podman：相当于docker的redhat版，符合k8s编排标准的容器

kubernetes：提供对容器的编排，提供完整的生成级解决方案，新版本已经放弃docker。



缓存中间件

作用

提高响应效率，减少数据库压力

技术方案

redis：支持多类型存储，3.0官方支持集群，6.0多线程模型

memcached

没有历史包袱，通常建议都选redis

消息中间件



作用

用于系统间解耦，流量缓存（消峰）



技术方案

早期的消息中间件（已淘汰）

rabbitmq（AMQP协议），zeromq，activitymq

现阶段的消息中间件：

kafka：超高吞吐，消息打包发送所以延时可能会不如rocketmq，0.8之前重度依赖zk（包括消费者的offsets，后面改成了内置主题），0.8之后zk 只做集群的管理

rocketmq：高吞吐，低延时，不依赖外部中间件（使用自带的nameserver）

pulsar：据说是下一代消息队列（没具体了解过）



数据库

作用

数据持久化



技术方案

mysql：主流关系型数据库，标准sql语法支持

MongoDB：BSON结构存储，4.0之后支持事务

TiDB：分布式存储、支持事务，兼容大部分mysql语法



数据采集

作用

采集应用数据、错误日志、系统日志、慢sql等各种数据

技术方案

logstash ：完整的数据采集方案，过滤功能强大（grok）

flume：完整的采集方案，提供可靠传输，可以结合kafka使用

beats：elasticsearch采集数据的agent，要过滤数据可以和logstash结合使用



搜索引擎

作用

存储内容，提供检索

技术方案

elasticsearch ：基于Lucene的搜索服务器，分布式存储。ELK的核心存储组件

solr：基于Lucene的搜索服务器，集群依赖zk，纯读的性能应该比es强一些，写入性能不如es（网上看的，没有实际验证）

得益于ELK的广泛应用，感觉solr并没有优势，没有历史包袱建议选择es



文件系统

作用

存储文件

技术方案

OSS：云服务商提供的文件存储服务，收费

Ceph：分布式文件系统（公司在用，个人没接触过）

fastdfs：分布式文件系统，适用小文件



缓存同步

要解决的问题

mysql的数据变更同步到 redis

技术方案

双写：在业务逻辑处理中同步更新redis，侵入性强，低延迟

消息队列：在业务逻辑中发送消息处理更新redis，侵入性强

读取binlog：databus/canal等开源解决方案，无侵入，需要mysql开启binlog



多级缓存

要解决的问题

热点页面或数据的高并发下快速响

技术方案

使用多级缓存，使请求命中请求链路中尽可能靠近用户端的缓存。

cdn缓存

nginx缓存

本地缓存

redis集群缓存

mysql缓存



统计功能优化



要解决的问题

通常统计功能都很复杂，早期写的复杂sql，在数据量上升到一定层度就会变成慢sql，消耗大量的cpu资源，频繁查询可能拖垮数据库。



解决方案

1.有效建立索引，去除分页（复杂sql分页很耗时且没有意义，通常默认返回1000页，每次都是只查询前几页，让管理员手动点下一页即可）

2.索引也不能起做用的时候，可以考虑伪实时，用定时任务统计，然后将结果存入统计表中，用户只做统计表的单表查询

3.需求不支持伪实时的情况下，可以考虑用消息队列或读binlog的方式，将增量数据同步到统计表。