hjy9725
获得徽章 0
- 学习了一篇关于redis缓存的文章，文章讨论了关于缓存更新策略的问题。首先，解释了为何需要缓存以提高数据响应速度，特别是使用 Redis 缓存。然后，提到了根据业务需求将数据分为不同级别并存入缓存的实例，如电商项目中的三个级别。对于从缓存读取数据的流程进行了简要说明。
随后，重点探讨了在缓存数据更新时可能遇到的问题，即更新缓存和更新数据库的原子性以及更新缓存的方法。给出了四种可能的策略：先更新缓存再更新数据库、先更新数据库再更新缓存、先淘汰缓存再更新数据库、先更新数据库再淘汰缓存。
最后，引入了三种经典的缓存模式：Cache-Aside、Read-Through/Write-Through、Write-Behind。
在选择适当的策略时，需要根据具体业务情况、性能要求和数据一致性需求来决定。综合考虑，可以根据数据更新频率、对数据一致性的要求以及业务复杂性来选择合适的缓存更新策略，以达到最优的性能和数据一致性。展开评论点赞 - 找了很久的一个问题，主要是关于docker中运行一个jupyter notebook的容器，但是搞成了root用户执行，在重启这个容器的时候，因为以下的报错一直重启失败。
[C 18:06:42.898 NotebookApp] Running as root is not recommended. Use --allow-root to bypass.
网上都是直接叫你修改配置文件中的allow_root = True
可是那也得能启动容器进去修改啊，现在是重启失败，都没法进去。。。
找到的解决方法分三步：
第一步，启动容器的（有效期1s钟）
第二步，生成（覆盖）原有的jupyter notebook配置文件
第三步，匹配字符串，取消注释，将False改为True
一条命令搞定：docker start <CONTAINER_ID> && docker exec -it <CONTAINER_ID> /bin/bash -c "cd /root/.jupyter && find . -type f -exec grep -l '# c.NotebookApp.allow_root = False' {} \; -exec sed -i 's/# c.NotebookApp.allow_root = False/c.NotebookApp.allow_root = True/' {} \;"
参考以下链接：
github.com
特别鸣谢：
chatgpt帮助我直接写了替换的shell命令展开评论点赞 - 在高可用系统设计中，常见的负载均衡策略有以下几种：
随机负载均衡：随机选择一个可用的服务器进行请求转发，简单且均衡，但不能保证每个服务器的负载相同。
轮询负载均衡：按照固定顺序依次选择服务器，实现请求的均衡分发，但无法根据服务器的负载情况进行动态调整。
加权轮询负载均衡：给每个服务器设置权重，根据权重比例选择服务器，可以根据服务器的性能和负载情况进行动态调整。
最少连接负载均衡：选择当前连接数最少的服务器进行请求转发，可以实现动态负载均衡，但需要实时监控服务器的连接数。
IP哈希负载均衡：根据请求的源IP地址进行哈希计算，将相同IP的请求转发到同一台服务器，可以实现会话保持，确保同一用户的请求都转发到同一台服务器。
最短响应时间负载均衡：根据服务器的响应时间来选择最快的服务器进行请求转发，可以提高系统的性能和响应速度。
动态负载均衡：根据服务器的负载情况实时调整负载均衡策略，比如根据CPU、内存、网络等指标进行动态调整。展开评论点赞 - 一. 负载均衡是确保服务高可用和高性能的关键技术之一。根据实现位置的不同，它可以分为三种解决方案：集中式LB（Proxy Model）是通过中心代理来分发流量；进程内LB（Balancing-aware Client）在客户端进程内部实现负载均衡；独立 LB 进程（External Load Balancing Service）通过一个外部独立的服务来实现负载均衡。
二. gRPC 是 Google 开发的远程过程调用系统，它默认使用 protocol buffers 作为序列化机制，但也支持其他格式如 JSON。gRPC 支持多种语言的客户端和服务器接口，为移动和服务器通讯提供了解决方案。展开评论点赞 - 根据贾岛在活动中的分享，蚂蚁金服移动网络接入架构经历了两个阶段的演进。
第一代架构是单应用架构，包括客户端APP和服务器，通过https进行通信。然而，随着无线业务的发展，单应用架构无法支持多业务多团队的并行研发，成为瓶颈。
第二代架构是API网关架构，将后端服务抽象为接口对外提供服务，支持多端应用接入。通过移动RPC研发模式，中间的通信细节由RPC框架负责，客户端只需关注业务。API网关架构提供了完善的API服务生命周期，从研发到发布上线、配置、运营等。还有监控体系，可以对API进行评分和预警。同时引入了无线RPC机制，简化了研发流程和提升了效率。
这些演进和优化使得蚂蚁金服能够更好地应对亿级并发场景，例如新春红包活动。整个架构设计和实践经验也得以在mPaaS中沉淀，为其他应用和企业提供了可借鉴和应用的价值。展开评论点赞 - 2、全双工
在传统的HTTP请求中，客户端发送请求后需要等待服务器的响应，这种单向的请求-响应模式限制了网络的效率和用户体验。为了实现全双工通信，我们引入了ACCS（阿里云通道服务），它是一个高性能、全双工的通信通道，可以同时支持客户端和服务器的双向通信。通过ACCS，我们可以实现实时消息推送、服务端推送、长连接等功能，大大提升了用户的购物体验。
3、低延时
移动网络的延时是影响用户体验的重要因素之一。为了降低延时，我们进行了多方面的优化。首先，我们优化了网络协议，采用了HTTP/2和QUIC协议，这些协议具有更高的效率和更低的延时。其次，我们通过异地多活和网络调度来优化网络路径，选择最快的路径传输数据。此外，我们还优化了DNS解析和连接池管理，减少了延时时间。展开评论点赞
github.com