def quick_sort(arr):
    """
    经典快速排序算法的 Python 实现（分治思想）
    
    参数:
        arr: 待排序的列表（支持数字、字符串等可比较类型）
    
    返回:
        排序后的新列表（原列表不会被修改）
    """
    # 基线条件：列表长度≤1时，本身就是有序的，直接返回
    if len(arr) <= 1:
        return arr
    
    # 选择基准值（pivot）：这里选列表第一个元素（也可选中位/最后一个，效果类似）
    pivot = arr[0]
    
    # 分治：将列表分为三部分
    less = [x for x in arr[1:] if x <= pivot]   # 小于等于基准值的元素
    greater = [x for x in arr[1:] if x > pivot] # 大于基准值的元素
    
    # 递归处理子列表，并合并结果：左半部分 + 基准值 + 右半部分
    return quick_sort(less) + [pivot] + quick_sort(greater)

# 主程序测试
if __name__ == "__main__":
    # 测试用例1：整数列表
    int_list = [3, 6, 8, 10, 1, 2, 1]
    sorted_int = quick_sort(int_list)
    print("原整数列表：", int_list)
    print("排序后：", sorted_int)
    
    # 测试用例2：字符串列表（Python 支持字符串按 ASCII 码排序）
    str_list = ["apple", "banana", "cherry", "date", "blueberry"]
    sorted_str = quick_sort(str_list)
    print("\n原字符串列表：", str_list)
    print("排序后：", sorted_str)

整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！

但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）：

1. 需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。
2. AWS Step Function 按状态转换收费，所以，贵得受不了了。

注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。

然后，Prime Video 的团队开始解决问题，下面是解决的手段：

1） 把 Media Conversion  和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.

2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。

EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因：

1. 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。
2. 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。