IT部门是如何从订单接受者转变为创新者的

2 语法服务响应

如前言的示例，用户在使用语法服务时，主要有以下三个请求：

每次打开文件获取所有的可点击高亮词

点击高亮词获取对应的定义与引用列表

点击定义和引用实现跳转

针对第一个请求，系统会构造基于文件路径的过滤条件构造ES的Query请求，将当前文件的所有高亮词坐标信息发送给前端，避免了前端做语法分词，没有构建好的文件自然也不会在页面上被高亮出来。另外，为了避免超大文件对ES的压力，前端会做分批动态加载。

针对第二个请求，我们在获取定义与引用列表的过程中，不光要得到文件名和位置信息，还需要将对应的代码内容展示出来，方便用户理解。为了实现这个效果，我们新增了批量获取文件片段的接口。

对于第三个请求，同一个文件内的跳转会自动高亮到对应的代码行，不同文件间的跳转会新开页面并跳转。

语法服务响应和语法索引构建是完全异步的，互不影响，支持独立的资源扩缩。

3 索引清理

语法服务的索引大小约是代码文件内容的数倍，比较消耗存储资源。所以针对用户通常的使用习惯和场景，制定了一系列索引清理任务来避免资源过度的损耗。

当代码评审合并或删除时，当分支删除时，系统会开始执行索引清理任务，释放索引资源。

四 语法服务展望

缺少符号跳转长久以来一直是页面上代码阅读的痛点之一，各种语法协议和技术层出不穷，如LSIF、Kythe、SARIF、UAST、Tree-sitter，ctags，全球技术人都在为更智能的代码分析，更好的代码体验，更高的代码质量做努力。云效语法服务后续也会逐渐加快语法构建速度，支持更多的代码语言，满足更多的语法场景，提升用户的代码浏览体验。
 

时序锁管理

根据库大小的区别，LSIF的索引构建时间为10秒至数分钟不等，而用户对同一个代码仓库的提交操作峰值可能会达到每分钟近百次，即使我们采用了增量技术也很难满足高频的构建请求，并且提交事件触达和调度任务执行无法保证精准的时序性。综上所述，我们需要一个分布式时序锁来保证任务调度的顺序和尽量减少重复调度。

当同一代码库的不同推动消息纷涌而至，Redis维护的分布式锁会做如下判断：若该库当前没有正在运行的任务，将任务置于队首，立即运行;若已有一个正在执行的任务，比较新来的Push消息是否是最新的，若是，则加入队尾;当队伍已有两个成员时，则将任务丢弃，因为每次执行任务时，系统都会克隆分支代码，基于最新的版本构建索引，如此就避免了多少次Push就需要执行多少次索引构建的可能性。考虑到线程意外退出的情况，队首会每隔5秒钟全局发送心跳，当队尾或新来的任务监听到心跳超时，则会将队首的任务放弃并执行新的任务。

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!