认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习软件编程开发的相关技术知识，而本文我们就通过案例分析来简单了解一下，软件开发缓存功能应用注意事项。

缓存对于任何一个系统来说，都是绕不开的一个话题，缓存设计好了对系统整体的性能往往是指数级的提升，但如是设计不好，对系统的稳定性和性能都是灾难性的影响，并直接影响系统整体的架构设计，但缓存部分的设计思想并不限于自定义表单，其他类似的系统都可以进行参考。

对于自定义表单来说，缓存比一般的系统依赖性更高，自定义表单定义产生的数据完全满足更新极少，查询极高的应用场景。可以想象，一个系统交付给客户之后，哪些情况还会重新发布，对于传统的项目，一般一年也没有几次，但是自定义表单时时刻刻都在查询，界面任何一个动作，都需要读取自定义表单数据的进行支撑，所以缓存对于自定义表单来说显得更加的重要，说到缓存，多数人一印象就是Redis等缓存服务器，但自定义表单的缓存我这里的设计完全不依赖于外部缓存服务器，缓存部分的设计有别于其他系统的缓存设计。

自定义表单产生的数据汇总到表单和视图实体中(表单和视图的设计参考之前文章介绍)，包括相关的控件、规则、行列数据、查询定义、界面控件样式等，都聚合到表单或视图中，表单和视图都会包含Id和Version字段，任何相关数据的变更，都会同步更新视图或表单数据，同时重新生成Version值。

将表单和视图实体的所有数据存储经过精简字段后存储到内存中(只存储逻辑上需要的字段。之所以选择存储到内存中，是因为自定义表单任何功能都需要读取定义数据，如果存储到Redis等外部缓存服务器，对外部服务器的访问量会非常大，且自定义表单数据定义往往不是几个字符，是很多数据聚合起来的，数据量相对来说比较大，且有些业务逻辑需要关联查询等。

自定义表单任何定义数据的更新，都会涉及到缓存的更新，对于单应用服务器不会存在任何的问题，但如果分布式部署的话就会引申出分布式缓存同步更新的问题，如果用独立的缓存服务器，也不会存在同步更新的问题，但这里的自定义表单缓存存储在应用服务内部，那么就需要借助于分布式的消息发布订阅功能的服务，自定义表单数据变更，发布变更通知，部署的自定义表单服务器订阅通知，收到变更通知时清楚自生内存缓存数据，等待读取缓存数据时，再从数据库读取数据更新缓存。

分布式发布订阅的服务很多，可以选择Redis或者Rabbitmq等，这里的发布订阅可以不用是可靠的发布订阅。另外还需要处理发布订阅服务器断开问题，发布订阅服务器断开后，所有数据都直接读取数据库数据，这个时候应用系统会非常缓慢(解决方案?)。

前端访问每个自定义表单页面，读取表单关联的表单和视图数据，存储到IndexDb中，以KeyValue的形式存储，每请求一个页面，判断IndexDb中是否存在表单数据，存在时，将关联的表单Id和视图Id及其版本号传到后端，后端判断版本号是否与后端缓存的版本号一致，如果不一致，将新的数据返回到前端，前端刷新IndexDb数据，然后再渲染数据。

前端每请求自定义表单后端接口数据时，将进入界面关联的表单Id和视图Id及其版本号写入Header，后端调用接口前进行拦截，判断版本号是有存在过期的情况，如果存在过期，则通知用户刷新界面，重新走加载页面判断版本号逻辑。这部分就是效果图看到的效果。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。