search

经验总结

hashtag
架构设计原则

1.合适优于业界领先:可以参考淘宝，但不要照搬淘宝 2.演化优于过度设计:不要设计过于超前的方案，演化也不要推倒重来 3.简单优于复杂:轮询大部分情况下都是很好的设计，不确定就穷举，不明确就轮询 4.重构优于重写:风险控制、经验传承、成本分散 5.硬件优于人工:能够用硬件解决的，不要用人工去解决，例如换 SSD，换更强的机器 6.专注优于全面: SRP 原则，一个系统只关注一个事情，JAE 的例子 7.开放优于封闭:亚马逊的例子，SOA、微服务 8.能用优于完美 9.重用优于自研 10.业务优于技术: Docker 很火，我们是否要引入? 11.存储优于运算:存储设计是架构设计的关键 12.技术优于流程:不要试图提升人的能力来保证质量，不要试图投入大量的测试来保证质量,而是尽量做到出问题能够快速发现和处理 13.分布优于集中 14.优化优于重构

hashtag
代码规范

  1. 表达清晰，不要嫌变量名字长

  2. 代表性名字放在最后

  3. 常量全大写，下划线隔开 如NAME_CONSTANT

  4. 抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。

  5. 避免在子父类的成员变量之间、或者不同代码块的局部变量之间采用完全相同的命名，使可读性降低。

  6. 方法内主干清晰，步骤明了

  7. 对象是过程的抽象，线程是调度的抽象

  8. 开闭原则、职责单一原则、最小惊异原则、墨忒耳律

hashtag
缓存的问题

缓存解决方案：

  • 双更新 (db -> cache / cache -> db) : 皆有风险

  • 更新后删除 (db -> delete cache) : 并发问题 cache ABA

  • 延迟双删 (update db -> delete cache, 隔断时间再删一次) : 实现问题(MQ/本地队列，多久再删合适)

  • 闪电缓存 (设置缓存过期时间为几秒) : 缓存击穿，并发请求全打到数据库 -> 可以使用本地锁或者分布式锁 (引入新的复杂度)

hashtag
Redis 分布式锁使用注意事项

  1. 如何使用锁(setnx key value expire time)

  2. 释放锁的时机(try-finally)

  3. 保证上锁的线程和解锁的线程是一样的

  4. 业务执行时间超过锁的生命周期的处理(异步续命)

详细见 -> [Redis]利用 Redis 实现分布式锁 https://www.cnblogs.com/jojop/p/14008824.html)

hashtag
网站的一些方案

  1. CSRF: 跨站点伪装请求，诱使用户点击有问题的站点，然后再有问题的站点发起请求，利用cookie的有效性，达到伪装成用户请求发送请求的目的。 解决办法： 使用token 校验(在发送请求时加上的)，而不用cookie(自动带上的)

Previous算法Next缓存使用建议

Last updated