大家都在做异地多活，得物基于自己的电商物流场景是怎么去设计架构的，又遇到哪些问题，让我们的研发同学来解答下。

管理学大师彼得 - 德鲁克曾说过：无数据不管理。数字是人们快速认知事物的一种有效方式。无论在生活还是工作，对事还是对人都息息相关。碰上难以用数字描述的事物或现象肯定是没有找对适用的指标和度量方式。尤其对于质量工程方面的工作，定量的呈现远比定性描述更有说服力。而“三级指标体系”就是质量平台在这一年的反复打磨中，逐渐清晰并成型的，能够将得物工程质量加以体系化度量的一种最佳工程实践。

在得物技术体系中，大量使用Redis作为缓存中间件，以应对高并发下的大流量场景。在使用缓存时，不得不考虑数据一致性问题，即保证缓存中的数据和DB始终可以保持一致。常规的解决缓存一致性的方案一般为先修改DB并提交事物，再操作缓存更新或者失效，为了应对极端场景往往会再采用延迟操作的方式进行缓存的二次处理。

但实际开发中，遇到很多代码不规范的场景，在JDBC事务中进行缓存删除或者更新等操作，带来的问题是当JDBC事务未提交就完成了Redis的操作，容易造成二者数据不一致。所以我们思考：既然Redis本身也提供了事务的解决方案，那能不能将Redis事务和DB的事务进行结合，来保证数据一致性的问题呢？接下来我们就带着这个问题看看看Redis事务的实现、使用，最终探索一下将Redis操作结合DB事务使用的可能性。

近几年，随着得物业务的快速发展，应用数目与实例规模在快速地增加。得物的注册中心也在不断的演进优化，以支撑业务的发展。从最初的 Nacos 到 Nacos Proxy 引进再到完全自研的 Sylas 替换 Nacos，期间遇到了哪些问题，如何解决这些问题，以及未来的演进方向，是本文主要探讨的内容。

本文通过对SidecarSet的源码按照SidecarSet CR的调谐过程、sidecar容器的注入过程和sidecar容器的升级过程 这三个模块做了分析，三个模块的处理流程有交叉，所以文中介绍时会有看到后面时又得回过头去看前面的现象。

IPv6 相对 IPv4 可以提供海量的网络地址，同时 IPv6 在协议上预留了广阔的创新空间，为互联网长期升级演进提供了新的基础平台，已成为全球下一代 互联网发展的核心方向，也是支撑我国互联网升级演进的唯一正确路径。

对于任何一家月活上亿用户的互联网公司来说，IPv6 升级改造都是一件很复杂的事情。很多同学可能好奇 IPv6 到底要怎么改造，本文将整体介绍下『得物 App 全场景 IPv6 改造』的项目经验，供大家参考。

得物是一家潮流文化的电商平台，用户在这里能够寻找、发现自己喜爱的潮流商品。交易推荐负责所有商品的流量分发，在得物商品推荐中发挥着至关重要的作用。个性化推荐效果不仅影响用户浏览体验，还关系着公司技术和品牌形象。

「小得物环境」是一套[全新搭建]独立[物理隔离]的[单地域]的[小流量][生产环境],覆盖了从网络、接入层、中间件、核心应用的系统和服务，为各类产品研发和业务发展的稳定性提供了丰富工具和应用场景。

在业务迭代中，随着数据量的上升，会出现慢SQL情况，但是当我们去分析单条SQL的时候，发现其执行速度并没有那么慢，原因是什么呢，那么就可能是RDS服务器IO产生了瓶颈。

互联网常见的高可用手段。比如服务冗余部署、异步化设计、负载均衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等，今天主要是一起聊下，多机房部署的灾备架构模式，来确保服务的高可用。

为了解决在维护 Web 图标库时所面临的痛苦，期望打造最友好的从设计到研发图标交付方案，我希望它们能让更多的开发者和设计师受益，让网站建设更简单、更快速，更高效。

分布式场景下，多个业务系统间实现强一致的协议是极其困难的。一个最简单和可实现的假设就是保证最终一致性，这要求服务端在处理一个重复的请求时需要给出相同的回应，同时不会对持久化数据产生副作用（即多次操作与单次操作的结果需要是业务角度一致的）。

一个API拥有幂等能力的话，调用发起方就可以很安全的进行重试。这符合我们普遍的假设。提供幂等能力是服务提供方需要做的事，所以本文是站在服务提供者的角度来写的，即下文的“我们”通常指的是服务提供方。

我们在进行代码重构以及需求迭代时，在上线之前需要进行一轮、二轮以及回归测试，如果业务场景比较复杂，那么就会存在以下几个方面的问题：

1. 测试的周期就会相应的拉的比较长；
2. 随着业务功能的不断迭代，测试案例不一定能够覆盖全，一些冷门的隐藏比较深的问题不一定可以及时发现，回归测试难度逐渐增大；
3. 影响发布频率；
4. 开发以及测试人员消耗在测试阶段时间比较长，不利于腾出时间进行下一步的业务迭代、技术改造等工作；
5. 代码质量很多时候依赖人为的code review，迭代代码行较多，code review占用时间较多；

为此，我们能否解决这些痛点，使得我们的工作效率得到一定的提升，以及我们代码的质量得到一定的保证，是我们需要思考的一个问题。业内的做法一般将线上的流量引入对比机器，将生产结果和对比机器进行实时对比，及时暴露问题，开发和测试能够及时发现并进行修改。

包体积优化，或者说包体积瘦身，相较于 crash 治理、卡顿优化、启动优化等比较硬性的指标来说，优先级可能没有那么高。特别是对于一些孵化期和成长期的 App 来说，用户量、DAU 没有上去之前，来进行包体积瘦身收益也不高。

在 Android 当前整个 CI / CD 流程中，组件或者App产物产出时缺少核心修改信息。由于修改信息的缺失，这会让开发困惑于该产物是否包含我最新的代码提交。

最近团队里我们在密集的讨论Redis缓存一致性相关的问题，电商核心的域如商品、营销、库存、订单等实际上在缓存的选择上各有特色，那么在这些差异的业务背后，我们有没有一些最佳实践可供参考呢？本文尝试着来讨论这个问题，并给出一些建议。