系统性能优化

经历

从刚参加工作到现在满打满算，有快4年时间了，期间优化过大大小小的服务，
2C2B的都有，基本上2C会严格些，因为它是面向用户的，用户体验好不好也直接
影响到用户的流失以及购买意愿等问题，响应时间尽可能在毫秒级，最慢不要超过
2秒，特别是核心的服务。2B的话只要不是特别慢，3到5秒都是可以容忍的,前提是
公司内部用户,对性能要求不是很高的受众。

展开全文 >>

业界使用elasticsearch经验研究

去哪儿

docker+k8s部署elasticsearch, 设定慢日志记录，
节点划分（data, master, hot, warm这些），分片数副本数
设定， opensearch系统的自助配置，监控和报警，监控数据汇总
审计日志，错误日志，访问日志。
PB级数据量写入和查询
使用场景：附近的人（GPS）, 报表，监控统计，物/车联网传感器数据，
日志实时分析，站内搜索（订单，产品，文档），
定期force merge (segment 是jvm消耗的主要者)

展开全文 >>

需求讨论什么内容？

需求评审的目的是为了搞清楚：

1、需求是什么，从哪里来，对业务的影响是什么，价值在哪里，
对开发的要求是什么。
2、需求是一次性的，还是需要分期实现的，是解决一个问题，还
是解决多个问题，扩展性如何，通用性如何。
3、需求如何实现，边界划分，业务方面有无配合的部分，开发方
面哪里有风险，哪里是难点，哪里是重点，有没有可以复用的部分，
周期如何，优先级怎样。
4、需求实现之后，可以达到的效果，对业务的帮助，等等

展开全文 >>

code review分享

一、背景

code review本质是鼓励开发者间更多的沟通，互相学习，营造技术文化氛围。
code review按照后面咋们讨论的check清单一项一项的检查, 以此来降低项目
出现的一些低级别的错误和没cover 到场景等错误. 定期总结和优化check 清
单, 熟悉模块之间的依赖, 后期逐步提高开发效率, 丰富全局考虑问题的思
维, 有利于开发之间学习和成长。code review 比较符合从有到优的发展阶段。
code review 的目标长期来看，收益是提升团队的项目质量，减少团队陷入反
复修复 bug 的困境中，让团队有机会去面对更多的挑战。
code review 对个人和团队而言都是成长的机会，要用开放的包容的心态去接
受不同的意见，取其精华。

展开全文 >>

java锁相关研究

轻量级锁和重量级锁

读多写少 => 用轻量级锁Reentranlock，原子类。其原理是CAS比较并交换
自旋递增(unsafe类do while)逻辑。
写多读少 => 用重量级锁synchronized，Lock。而synchronized的实现原
理是依赖操作系统的互斥锁实现线程的同步。

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

主动起来，<br>马上就不一样，<br>能量马上就不同，<br>就算你是一穷二白，<br>只要你有足够的创造性，<br>只要你有足够强大的情绪肌肉，<br>你想要的也会源源而来，<br>情绪肌肉和身体肌肉都是需要锻炼和训练的。