1. 项目背景与核心需求
旅游行业正经历数字化转型的关键时期。根据文旅部最新数据，2023年全国在线旅游预订市场规模已达1.2万亿元，同比增长28%。但传统票务系统普遍存在三大痛点：高峰期并发处理能力不足（如故宫旺季日访问量超8万次）、数据价值挖掘不足（85%的景区数据处于沉睡状态）、支付成功率波动大（峰值时段掉单率可达15%）。
这个基于Django+Hadoop的解决方案，正是针对这些行业痛点设计的分布式系统。我在实际开发中发现，要同时满足以下核心需求：
- 毫秒级响应：春节/国庆等高峰时段需支撑10万+QPS
- 实时数据分析：用户行为埋点数据延迟需控制在5秒内
- 支付高可用：保证99.99%的支付接口可用性
- 智能推荐：基于Hadoop的协同过滤推荐响应时间<500ms
2. 技术架构设计解析
2.1 整体架构分层
系统采用经典的四层架构，但在数据层做了创新设计：
code复制[客户端层]
↓ HTTPS/WebSocket
[接入层] Nginx+Keepalived（双活部署）
↓ gRPC
[业务层] Django+DRF（横向扩展容器组）
↓ Kafka
[数据层]
├─ 实时计算：Spark Streaming
├─ 离线分析：Hadoop+Hive
└─ 事务处理：MySQL集群（主从+分库分表）
2.2 关键技术选型对比
在支付系统选型时，我们对比了三种方案：
| 方案 | 吞吐量 | 开发成本 | 合规性 | 最终选择 |
|---|---|---|---|---|
| 支付宝原生SDK | 8000TPS | 低 | 完全合规 | ✓ |
| Stripe国际版 | 5000TPS | 中 | 外汇限制 | ✗ |
| 自建支付网关 | 3000TPS | 高 | 需PCI认证 | ✗ |
实测发现支付宝的异步通知机制需要特别注意：必须实现幂等性处理。我们通过redis+lua脚本实现了分布式锁方案：
python复制def alipay_callback(request):
lock_key = f"pay_lock:{trade_no}"
with redis_lock(lock_key, timeout=10):
if Payment.objects.filter(trade_no=trade_no).exists():
return HttpResponse("success")
# 实际业务处理...
3. 大数据处理模块实现
3.1 Hadoop集群调优实战
在阿里云EMR上部署Hadoop时，这些配置参数至关重要：
xml复制<!-- yarn-site.xml -->
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>物理内存的80%</value>
</property>
<property>
<name>mapreduce.map.memory.mb</name>
<value>2048</value>
</property>
<!-- 避免OOM的关键设置 -->
<property>
<name>mapreduce.reduce.shuffle.input.buffer.percent</name>
<value>0.7</value>
</property>
踩坑记录：最初直接使用默认配置导致频繁OOM，通过以下监控指标定位问题：
- Container被Kill次数（yarn logs -applicationId）
- GC时间占比（jstat -gcutil）
- Disk IO等待时间（iostat -x 1）
3.2 用户行为分析流水线
基于Flume+Kafka+Spark的实时处理方案：
code复制[埋点SDK] → [Flume [Agent]](https://taotoken.net?utm_source=general) →
[Kafka Topic] →
[Spark Streaming] →
[Redis HyperLogLog] ← 实时UV统计
↓
[HDFS Parquet] → [Hive] ← 离线报表
一个典型的口碑分析作业：
python复制# Spark SQL处理评论情感分析
df = spark.read.parquet("hdfs://comments/*.parquet")
result = df.withColumn("sentiment",
udf_analyze_sentiment(col("content"))) \
.groupBy("scenic_id") \
.agg(avg("sentiment").alias("avg_score"))
4. 高并发预约系统实现
4.1 库存超卖解决方案
对比测试了三种方案后的选择：
- 悲观锁（select for update）：并发100时RT达2s ✗
- Redis原子递减：存在库存不一致风险 ✗
- 最终方案：Redis+Lua+异步扣减
lua复制-- ticket_reserve.lua
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock <= 0 then
return 0
end
redis.call('DECR', KEYS[1])
return 1
调用方式（Django集成）：
python复制from django_redis import get_redis_connection
def reserve_ticket(scenic_id):
r = get_redis_connection()
script = """
-- 上面的lua脚本内容
"""
success = r.eval(script, 1, f"stock:{scenic_id}")
if success:
async_task('tasks.actual_deduction', scenic_id)
4.2 支付系统容灾设计
支付链路采用双通道设计：
code复制主通道：支付宝APP支付 → 支付成功率达98.2%
备通道：H5快捷支付 → 成功率95.7%但支持断网续传
关键容灾措施：
- 本地交易日志表（MySQL+binlog同步）
- 对账任务每小时跑一次（差异率<0.01%）
- 补偿任务自动重试（最多3次）
5. 性能优化关键指标
经过3轮压测优化后的结果：
| 场景 | 优化前 | 优化后 | 手段 |
|---|---|---|---|
| 门票查询 | 1200QPS | 8500QPS | 二级缓存+布隆过滤器 |
| 支付创建 | 300TPS | 2100TPS | 数据库连接池调优 |
| 推荐计算 | 2.3秒 | 380毫秒 | 预计算+RedisGears |
| 数据导入 | 1h/file | 15min/file | Hadoop小文件合并 |
特别提醒：Django ORM在分页查询超过10万条时会暴露出性能问题。我们的解决方案是：
python复制# 错误做法（导致内存溢出）
queryset = TicketOrder.objects.all()[100000:100020]
# 正确方案（游标分页）
def cursor_paginate(last_id=None):
qs = TicketOrder.objects.order_by('id')
if last_id:
qs = qs.filter(id__gt=last_id)
return qs[:20]
6. 部署方案与监控体系
6.1 混合云部署架构
生产环境采用独特的"云主机+容器"混合方案：
code复制[阿里云ECS] ←→ [自建K8s集群]
├─ 有状态服务：MySQL、Hadoop NN
└─ 无状态服务：Django Pods（HPA自动扩缩）
网络拓扑中的关键配置：
nginx复制# 动静分离配置
location ~* \.(js|css|png)$ {
expires 30d;
add_header Cache-Control "public";
proxy_pass http://static_backend;
}
# API限流配置
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
6.2 立体化监控方案
我们搭建的监控体系包含：
- 基础监控：Prometheus+Node Exporter
- 关键指标：CPU steal时间（云厂商超卖检测）
- 业务监控：ELK日志分析
- 重点监控：支付链路trace_id追踪
- 大数据监控：Grafana+Hadoop Dashboard
- 核心看板：HDFS块丢失预警
一个典型的告警规则配置：
yaml复制# prometheus/rules.yml
- alert: HighPaymentFailure
expr: rate(payment_failed_total[5m]) > 0.05
for: 10m
labels:
severity: critical
annotations:
summary: "支付失败率超过5%"
7. 安全防护实践
在金融级安全方面，我们实施了这些措施：
-
动态风控引擎（规则示例）：
python复制class RiskRule: @staticmethod def check_geo_velocity(user): """5分钟内异地登录检测""" last_loc = UserLocation.objects.latest() if distance(current_ip, last_loc.ip) > 300: # 公里 if (now() - last_loc.time) < timedelta(minutes=5): raise RiskException("异地登录风险") -
敏感数据加密方案：
python复制# models.py class Payment(models.Model): card_no = EncryptedCharField() # 使用AWS KMS信封加密 def get_card_no(self): return decrypt(self.card_no) -
Hadoop安全加固：
bash复制# 启用Kerberos认证 hadoop.security.authentication=kerberos hadoop.security.authorization=true
8. 项目演进与经验总结
在半年多的生产运行中，我们积累的关键经验：
-
数据一致性保障：
- 采用TCC模式处理分布式事务
- 最终一致性检查任务跑在K8s CronJob
-
成本优化技巧：
- Hadoop冷数据自动转存OSS（节省60%存储成本）
- Spot Instance运行Spark作业（降低70%计算成本）
-
团队协作规范：
git复制# Git提交规范 feat: 新增支付宝刷脸支付 #A123 fix(booking): 修复库存超卖问题 #B456
一个典型的迭代周期：
code复制周一：需求评审（使用Figma原型）
周二：技术方案设计（架构图评审）
周三：开发（结对编程+Sonar检测）
周五：压测（JMeter+火焰图分析）
这个项目让我深刻体会到：大数据系统不是简单技术的堆砌，而是要在业务价值与技术成本间找到平衡点。比如我们最终放弃了实时数仓方案，转而采用"准实时批处理"，用15分钟的数据延迟换取了3倍的性能提升和50%的成本下降。