在并发场景下，缓存删除与数据库更新的顺序是一个关键问题，究竟该先删缓存还是先更新数据库，需要我们深入探讨。

先删缓存，再更新数据库，这种方式看似简单直接。在数据发生变化时，先将缓存中对应的旧数据删除，确保后续请求不会从缓存中获取到旧数据。然后再去更新数据库，让数据库保存最新的状态。在大多数情况下，这个流程能保证数据的一致性。比如一个电商系统中商品价格发生了变动，先删除缓存中该商品价格的缓存数据，接着更新数据库里的价格信息。后续用户请求时，由于缓存中没有旧数据，会从数据库读取最新价格并重新写入缓存，保证用户看到的是最新价格。

然而，这种方式存在一定风险。在高并发环境下，如果先删除缓存后，更新数据库操作因为某些原因（如网络异常）失败了，而此时另一个请求过来查询数据，由于缓存已被删除，会直接从数据库读取数据，就会读到旧数据，从而导致数据不一致。

另一种方案是先更新数据库，再删除缓存。先确保数据库中的数据是最新的，然后删除缓存，让下次请求能够获取到最新数据。这种方式能在一定程度上减少数据不一致的风险，因为数据库更新成功后再删缓存，保证了数据最终一致性。但同样也有问题，在并发场景下，如果更新数据库后，还没来得及删除缓存时，有请求过来读取数据，此时读到的依然是缓存中的旧数据。

所以，无论是先删缓存还是先更新数据库，都有其优缺点和适用场景。在实际开发中，我们需要根据业务场景的并发量、数据一致性要求等因素综合考虑。例如，对于一些对数据一致性要求极高、并发量又相对较小的场景，可以优先考虑先更新数据库再删缓存，并通过一些补偿机制来处理可能出现的异常情况；而对于并发量较大，但对数据一致性要求不是绝对严格的场景，先删缓存再更新数据库并配合重试机制或许是个不错的选择。只有深入理解并合理运用这两种策略，才能在并发场景下保障系统的数据一致性和稳定性。