答案取决于你的负载、你当前和潜在的未来需求、你对各种工具和框架的熟悉程度等。我将重点介绍Kafka，因为我对它很熟悉。google pub/sub或kinesis的语义是相似的，因此下面的内容应该是适用的。
大约1）
json反序列化性能可能因语言而异，但它是一种内存操作。因此，我怀疑这将是你的管道瓶颈。每种语言都有多个json编码器/解码器，这意味着在一种语言的工具系列中有优化的空间。这里可以找到一个基于python的小基准。我的观点是，你不应该使用你不熟悉的语言；你可以用你喜欢的语言找到一个性能解决方案。
在我不久前做的一个基准测试中，一个kafka使用者在flink上（用scala编写）在aws上以~3k/s的速度从kafka获取并反序列化json消息（每个消息约1-2kb）。这是为了提供一个数量级的指示，您应该期望从每个并行进程。这是远远没有优化，我很肯定这可以高达一个数量级，如果适当优化。我想说的是，如果你收到的信息数在每秒100秒/1公里的范围内，你不必担心那么多。您可以很容易地设置这样一个实验，使用json消息并添加一个json反序列化步骤。
大约2，3）
Spark流是完全相同的系统类型作为Flink和风暴。它们是分布式流处理器，能够部署大型（和有状态的）流拓扑，可以扩展到100k-1m消息/秒。但是，它们需要部署在集群上（我通常选择yarn，但它可以是mesos，也可以作为独立的或kubernetes等）。对于您描述的用例，它们可能是一种过度的杀伤力。
kafka消费者组在该组的消费者中均匀地分布主题分区。如果一个使用者死亡，分配给它的分区将在其余使用者之间进行负载平衡。如果添加了另一个使用者，分区将重新平衡。消费者通过向Kafka承诺补偿来标记他们的进步，因此Kafka确切地知道在失败的情况下消费者会留在哪里。有些情况下，已处理的偏移量将无法提交并因此重新处理（至少一次语义），但假设您的操作被设计为幂等的，您就可以了。
您可以设计一个解决方案，其中许多并行的无状态kafka消费者在一组容器上处理和持久化消息，并实现您的目标。我的印象是连接转换（正如@dawsaw所提到的）太前沿了，但我可能错了。