关键点：
1000wPDF：数据量非常大。
3天处理完：有时间限制。
一篇PDF1~10s：可能需要以最高10s去做计算，这样时间才能保证留有富余。
要求资源最大化利用：也就是尽可能节省服务器资源，能复用尽量复用，包括应用服务器和OSS服务资源。
服务器都是阿里云的：可以假设都在同一个机房，忽略网络I/O时长损耗，这样可以用本地耗时作为计算的依据。
时间计算：假如一篇PDF处理10s，三天一台机器处理32460*6=25920（份）PDF。
假如一篇PDF处理1s，三天一台机器处理32460*60=259200（份）PDF。
也就是一台机器三天处理量最多259200，最少处理25920份。那么1000w最多需要10000000/25920 ≈ 386台机器，最少需要39台机器。
优化思路：思路一：动态缩容 ，先以386台机器并行处理，假设第一天处理数据量超过三分之一，此时计算剩余待处理量按10s算需要多少台机器，理论上所需机器数N<=386。机器数可减少到N台，再过一天后再次计算所需机器数newN<=386，机器数再次缩减到386台。也就是我们将时间段分成了3份，因为一篇PDF处理时长1~10s，所以每次一定是可以缩减0-N台服务器。这个分段可以更细到9段、24段、72段等，这样可以更多地缩减服务器数量。
思路二：多线程 ，鉴于现在一台服务器一般情况下是多核的CPU，所以可以充分利用多线程的优势。使用线程池可以更好地避免线程的创建和销毁的损耗，这里的处理程序可以使用线程池来进行相应处理。线程数建议按CPU核心数 *（1+平均等待时间/平均工作时间）计算。
思路三：分布式任务调度，由于有多线程+多实例，所以需要有一个高效的分布式调度组件来进行任务分配，避免资源的竞争和任务失败重试等。这个可以使用一些分布式任务调度框架，如XXL-JOB，基于自己的业务属性自主开发一个任务调度平台。或者可以使用消息中间件的方式进行任务的生产+消费，消息中间件消费一般是自带多线程的。