答：本地内存+redis
答：当redis预减库存为0的时候，这个就需要改为false
在秒杀系统设计中，"内存标记"和"Redis预减库存"都是优化手段，旨在减少对数据库的访问以提高系统的性能。但在缓存的层级分类中，这两者的位置可以如下解释：
内存标记：它直接在应用程序的内存中进行，速度非常快。因为这种操作不需要与任何外部系统通信，所以它通常被视为一级缓存。
Redis预减库存：Redis是一个外部的内存存储系统，虽然它非常快，但与直接在应用程序的内存中进行操作相比，访问Redis会涉及到网络通信的延迟。因此，从缓存的层级分类角度来看，Redis通常被视为二级缓存。
所以，简而言之，内存标记是一级缓存，而Redis预减库存是二级缓存。
一级缓存和二级缓存的区别通常基于以下特性或标志来定义：
存储位置：
生命周期：
数据共享性：
访问速度：
失效策略：
复杂性：
根据上述特点，开发者可以根据实际需要选择使用一级缓存、二级缓存或两者结合，以优化应用程序的性能。
确实，根据数据存取的速度和距离CPU的逻辑远近来判断缓存层级是非常直观的方式。在计算机架构中，这种分类方式常被用来描述CPU的缓存层级（L1、L2、L3等），其中距离CPU核心越近、速度越快的缓存被视为更低的层级。
对于应用层面的缓存：
一级缓存：通常指直接存储在应用进程中的缓存，如Java对象在JVM堆上的存储。这种缓存的访问速度极快，不涉及任何跨进程或网络通信。
二级缓存：涉及到跨进程通信或网络通信的缓存，如Redis、Memcached等分布式缓存系统。虽然它们仍然是内存存储，但由于涉及通信，访问速度相对较慢。
你的观点完全成立。如果数据首先同步到Redis然后再同步到内存标记，那么可以将Redis视为一种“前置缓存”或“缓冲层”，而应用内存中的标记则可以视为更接近实际数据处理和业务逻辑的一级缓存。
这种层级化的缓存策略使得应用能够更加灵活地处理高并发情况，同时确保数据的一致性和系统的响应速度。
答：使用内存标记就不需要和远程主机进行网络通信
答：有可能的，因为redission可能会发生数据丢失，redis集群本身只能保证最终一致性
答：对，但是这种概率很低，因为一个redis集群连续发生多次主从切换的可能性很小
答：对，会显示排队中，客户端会不断轮询后端暴露出来的一个查询订单的接口，查看是否存在，这个接口会增加这个订单到redis缓存中
答：这个时候，客户端只涉及到查询订单操作，而不涉及到修改，而且只有这一个服务端线程会修改redis缓存，所以可以采用先更新mysql，再删除redis
答：
当用户下单后没多久又取消订单，或者下单后未支付，系统需要有一套相应的处理机制。这些机制通常涉及订单的生命周期管理、库存管理、支付超时等。以下是一些常见的处理方式：
订单取消：
未支付的订单：
总之，对于用户的取消订单或未支付行为，系统应该有一套完整的策略和流程，确保商家的利益和其他用户的正常购买体验不受影响。
答：
一级缓存通常指的是业务服务器本地的内存缓存，例如Java中的ConcurrentHashMap或其他本地缓存工具。更新一级缓存的方法和策略如下：
答：
缓存并发的问题确实是一个需要关注的点。根据不同的缓存类型和策略，处理方式也会有所不同。
Redis缓存：Redis是单线程模型，它确保了每次只有一个命令在执行，因此不会有并发冲突。但在分布式应用中，多个客户端同时发送命令到Redis可能会造成读旧数据的情况。为了避免这种情况，可以使用Redis的事务功能或乐观锁来确保数据的一致性。
本地内存缓存：在多线程环境中，本地缓存可能会出现并发的问题。例如，当一个线程正在更新缓存数据时，另一个线程可能正在读取这些数据。为了解决这个问题，可以使用并发工具，如Java中的ConcurrentHashMap或ReadWriteLock。ConcurrentHashMap允许多个读线程并发进行，但写操作会被锁定，确保每次只有一个线程可以写入。ReadWriteLock也提供了类似的功能，但提供了更细粒度的控制。
综上所述，确保缓存的并发安全是关键，需要根据实际情况选择合适的工具和策略来实现。
答：假设一条订单的初始值为0，表示用户下单但是仍然未支付，1表示成功支付了，待发货中，2表示用户主动取消订单了，3表示过期没有支付所以取消订单，4是终态，不会再变化了。
答：消费者主动从kafka消息队列中拉取下单消息，进行消费的时候，会进行下单操作。
答：
（1）用户点击下单按钮会生成一笔订单，此时订单的状态是0，消费者主动从kafka消息队列中拉取下单消息，进行消费的时候，会进行下单操作，此时变成初始状态0
（2）用户主动调用取消订单的接口，会使得状态由0变为2
（3）用户调用支付接口，状态由0变为1
（4）用户过了三十分钟没有支付，延时消息会到期被消费，将订单状态由0变为3
（5）用户收到货之后点击收货按钮，就会变为终态
答：考虑到新增的状态，我们可以定义以下状态值：
5 - 退换货中
6 - 退换货完成
7 - 退款中
8 - 退款完成
9 - 交易关闭
基于以上的状态定义，以下是各状态间的可能流转以及在什么时间点流转：
用户点击下单按钮
用户行为：点击下单按钮
状态流转：初始 -> 0 (未支付)
用户取消订单
用户行为：主动调用取消订单的接口
状态流转：0 (未支付) -> 2 (用户主动取消)
用户支付
用户行为：调用支付接口
状态流转：0 (未支付) -> 1 (已支付待发货)
用户超时未支付
系统行为：处理延时消息
状态流转：0 (未支付) -> 3 (过期未支付)
用户确认收货
用户行为：点击收货按钮
状态流转：1 (已支付待发货) -> 4 (交易完成)
用户申请退换货
用户行为：点击申请退换货
状态流转：4 (交易完成) -> 5 (退换货中)
退换货完成
系统行为：确认退换货请求已处理
状态流转：5 (退换货中) -> 6 (退换货完成)
用户申请退款
用户行为：点击申请退款
状态流转：4 (交易完成) 或 6 (退换货完成) -> 7 (退款中)
退款完成
系统行为：确认退款已处理
状态流转：7 (退款中) -> 8 (退款完成)
交易关闭
系统或用户行为：在任何非终态下，由于某些原因（如长时间不活跃、交易异常等）交易关闭
状态流转：任意状态 -> 9 (交易关闭)
以上流转可能因业务需求的具体性而有所不同，但大致能够涵盖大部分场景。
答：加减
增量库存：
全量库存：
在实际的库存管理系统中，增量库存和全量库存都有其应用场景，具体使用哪种方式取决于业务需求和系统设计。
除了年终盘点，还有什么全量库存的应用场景呢？
新商品上架：当商店引入新的商品时，需要为这些商品设置初始的库存量。这是一个全量库存的操作，因为是直接设置商品的库存，而不是基于现有的库存进行加减。
退货和换货：当客户退回或换货时，可能需要对库存进行调整。在某些情况下，这种调整可能是全量的，例如直接设置某个商品的库存为特定的数量。
库存调拨：在大型的零售或仓储企业中，可能需要在不同的仓库之间进行库存调拨。当某个仓库收到调拨的商品时，可能会直接设置这些商品的库存，而不是基于现有的库存进行加减。
库存纠错：如果发现之前的库存记录有误，可能需要进行库存纠错。这通常是一个全量库存的操作，因为是直接设置商品的库存，而不是基于现有的库存进行加减。
年终盘点：在零售或仓储行业中，通常在年底会进行一次全面的库存盘点。在这个过程中，员工会手工点验每一件商品，然后将实际的库存数量录入系统。由于这是一个全面的盘点，所以不考虑之前的库存数量，直接将系统中的库存值设置为盘点后的实际数量。这就是一个典型的全量库存的应用场景。
增量库存的幂等性怎么保证：
全量库存的幂等性：
全量库存的幂等性相对容易保证，因为每次都是设置一个固定的值，不依赖于之前的状态。只要确保每次设置的值是相同的，那么多次操作的结果也是相同的。但在实际操作中，还需要考虑以下几点：
是的，增量库存同样可以使用以下的版本控制方法：
答：秒杀主要体现在系统的短时间内需要处理大量用户的并发请求，特别是在秒杀活动开始的那一刹那。因此，秒杀系统的吞吐量需求非常高，以确保在短时间内处理尽可能多的用户请求，同时确保系统的稳定性和可用性。
答：极限吞吐量通常通过压力测试得出。在控制条件下，我们会逐渐增加发向系统的请求，并监控系统的响应时间和错误率。当我发现进一步提高线程数或并发请求时，tps开始下降或系统响应时间显著增加，这时的吞吐量就是系统的极限吞吐量。
答：有这种可能性。发压工具或者发压机本身也可能成为瓶颈，特别是当它所在的硬件资源不足或网络带宽受限时。这也是为什么在进行压力测试时，我们也要监控发压机的资源使用情况。
答：本地，16GB的内存，8核心，首先我是在本地进行压测的，它不涉及到远程通信，此外它的秒杀接口返回的信息量很少，各个服务也是本地部署，也就是说本机进程之间的通信速度也很快，这样就是说开的这些线程并发数虽然很高，但是也会很快释放资源，或者说执行完的线程会被重用。
答：要提高TPS，首先需要识别当前的瓶颈。这可能涉及到CPU、内存、数据库、网络等多个方面。优化可能包括对Redis进行水平扩展，对各微服务进行集群部署和负载均衡，优化数据库查询和索引，甚至考虑使用更高效的硬件。
答：不完全是。提到Redis的水平扩展是基于它常常是高并发系统中的一个瓶颈点。但真正的瓶颈可能涉及多个方面。为了确定真正的瓶颈，需要进行深入的性能分析和监控。
答：
（1）如果目的是提升整个微服务后端系统的总体tps，那么发压方的机器也需要进行集群部署，并在每个机器上随机访问不同的接口，以模拟真实的分布式环境。
（2）对于提升秒杀接口的tps，我认为订单处理服务可能是一个主要的瓶颈，因为它涉及到库存的扣减和订单的生成。因此，订单服务集群的水平扩展可能是个好选择，这样可以提高它的CPU处理能力，从而提高整体的tps。
答：
您提到的问题确实是在设计异步下单系统时需要考虑的关键点。即使下单操作是异步的，用户仍然需要得到一个明确的反馈来知道他们的下单请求是否被接受，以及是否可以继续支付。以下是一种可能的解决方案：
预下单响应：当用户点击下单按钮后，系统立即接收请求并将其放入消息队列中进行异步处理。同时，系统可以立即返回一个预下单的响应给用户，这个响应可能包含一个订单ID或一个跟踪号，以及一个提示信息，例如“您的订单正在处理中，请稍候”。
轮询或WebSocket（重点）：在用户端，可以使用轮询或WebSocket等技术来定期查询订单的状态。当订单处理完成（无论成功还是失败），系统会更新订单状态。用户端在检测到订单状态变化后，可以根据新的状态给用户提供相应的反馈。例如，如果订单处理成功，可以引导用户到支付页面；如果订单处理失败，可以给用户显示一个错误消息。
通知机制：除了轮询或WebSocket，系统还可以使用其他通知机制，如推送通知，来告知用户订单的状态变化。
超时处理：为了避免用户长时间等待，可以设置一个合理的超时时间。如果在这个时间内订单仍然没有被处理，可以认为订单处理失败，并给用户显示一个超时错误消息。
优化异步处理速度：虽然下单操作是异步的，但仍然应该尽量优化其处理速度，确保大多数订单可以在很短的时间内被处理。这样，用户在等待订单处理的时间会尽量缩短，提高用户体验。
通过上述方法，即使下单操作是异步的，用户仍然可以得到明确的反馈，并在适当的时候被引导到支付页面。