Kafka存储结构中的每个主题分区对应一个大文件，每个大文件由多个小文件段组成。
其中，Producer负责大文件的“顺序写入”，Consumer负责文件的“顺序读取”。
Kafka的存储架构可以简单理解如下： Kafka在写入数据时，通过将数据追加到文件末尾来实现顺序写入。这样做的好处是不执行读操作。阻止写操作。这也是吞吐量高的原因。
理论上，只要有足够的磁盘空间，Kafka就可以积累无限数量的消息，这使得它特别适合处理日志收集等场景。
目前流行的实时处理工具有Storm、Spark Streaming、Apache Flink。
Apache Flink 之所以受欢迎，不仅是因为其强大的性能（阿里巴巴采用该技术后，在一次活动中每秒可以处理17 亿条数据）；
它还具有容错机制，保证每条数据只处理一次，以及时间窗口功能。
在实际业务场景中，当需要基于时间范围进行统计时，往往会根据消息的事件时间来进行统计。
Apache Flink 的独特之处在于它使用基于消息的事件时间而不是基于框架的处理时间计算。这是Apache Flink 的另一个优势。
不同的流处理框架采用不同的容错机制来保证不同的一致性。
1）At-Most-Once:表示该消息只被消费处理一次，无论后续处理是否成功，有数据丢失的可能。
2）Exactly-Once:表示消息在被消费后、后续处理成功之前恰好出现一次。
3）At-Leat-Once：至少一次。表示一条消息被消费到后续成功处理之间的时间可以发生多次，并且可能会被重复消费。
架构流程：
1）后台服务器记录所有请求数据并保存到本地日志文件。
2）使用数据采集框架Logstash从日志文件中提取原始日志数据，直接保存到Kafka中，无需处理。
3）通过Apache Flink从Kafka获取原始日志数据，业务处理后分别存储到Elasticsearch、HBase、MySQL中。
4）Elasticsearch用于处理用户对请求日志的查询请求，将查询关键字段值和请求ID存储在索引中，根据查询关键字检索结果ID列表，并使用结果ID获取详细信息。 HBase 请求数据。
5) MySQL存储一些合并和处理后的支付数据。数据查询和支付处理请求量较低。
闪购如何运作
限时抢购架构原则：
遵守规则，不要过度销售您的产品
成功下单数据不会丢失
服务器和数据库不崩溃
防止机器人拿走您的产品
规划闪购架构是一个不断过滤请求的过程。目标是尽可能高层处理用户请求，并防止用户请求流向较低层。
静态资源和负载均衡
CDN：更快的响应时间，无需花费您自己的服务器资源和带宽。静态资源压力被隔离在系统层之外。
实现动态请求的方式有3种。
1）通过JS（JavaScript）在后台动态调用。动态数据可以与页面集成并放入CDN。也可以将其放置在Redis 缓存中。
2）JS访问服务器获取服务器时间的请求可以直接放在静态资源或者负载均衡层，用户请求不会进入系统下游。
3）放入饼干中。
一般来说，当涉及到用户查看页面时的行为时，CDN、静态资源或负载均衡器应尽可能拦截用户的请求。如果这确实不可能，您还必须在缓存中拦截它。
网关页面如何拦截上游请求？
那么如何在网关级别实现请求过滤呢？您可以做出三个限制。
1）限制每个用户的访问频率，例如每5秒点一次。在nginx上很快配置完成
2）限制每个IP的访问频率。 nginx上的配置很快就完成了。这个方法是为了防止有人通过机器人自动下单，误杀真实用户。
3）在一定时间内拦截一定比例的请求，或者保证只有一定数量的请求进入后台服务器。您可以在此处使用限流漏桶或令牌桶算法。
过滤后端服务器请求：目标不再是过滤请求的方法，而是避免过度销售产品的方法。
1）商品数据放置在缓存的Redis中（闪购期间不进行上架或变更等业务操作，即由业务流程而非技术来保证）。
2）订单写入缓存
3）订单分批进行
4）如果Redis停止工作（挂掉）怎么办。
例如，如果Redis读取库存失败，则直接访问数据库减去库存，并在数据库中构建增量和减量逻辑。
如果将订单写入缓存失败，则将订单数据直接写入数据库，避免处理后续批量dropout 逻辑。
如何拦截上游支付页面的请求
这个链接除了保证数据一致性之外，还有一个很重要的点：
如果您的业务逻辑由于错过付款而取消订单，请不要忘记添加您的数据库和Redis 库存。
总体来说：静态资源服务器、网关、后端服务器都必须配置负载均衡，缓存Redis和数据库必须配置集群模式。
以上#caching层持久化相关内容来源网络，仅供参考。相关信息请参见官方公告。
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/91848.html
