扫码关注官方订阅号
走同样的路,发现不同的人生
应该使用观察者模式
没有真正意义上的即时系统,所以,只可能是尽可能优化处理逻辑及效率,让用户察觉程序过程是一个平滑的过程。题主前边举的图片修改读取的例子并不是很恰当,既然要后台修改图片又想用户能获取修改后的图片,那这期间的等待过程是一个必须的过程,难不成你还想把不完整的或是错误的数据展现给用户?这种情况,加锁等待是正确的方式,不过也涉及到数据量大小、逻辑处理耗时的问题,实际情况还要复杂得多,网络异常超时、存储空间状况、数据加工等,
在用户交互层,小量数据可加锁等待和超时处理,这应该是可接受的延迟
大量数据及复杂逻辑的后台处理,可采用通知更新的方式,后台处理完了再通知交互层调用更新
做到这两点,就应该有不错的体验了。
加锁,程序写入时用户不许读取
设置一份缓存数据,然后定时更新当前修改的数据。
就你题目中的问题,想要及时读到更改的信息,就必须把同步操作优化到最小的范围,在绝大部分情况下可以线程并行,在真正的读写时候才会有同步操作
没太看懂,直接更新用户所看到的部分不就行了吗?你的意思是不是更改了信息,用户没有重新加载页面,所以看不到?如果是这样的话,完全可以在修改信息完成后刷新UI,同步直接在操作完成后刷新,异步在callback里刷新。如果是文件,则重新载入。
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
应该使用观察者模式
没有真正意义上的即时系统,所以,只可能是尽可能优化处理逻辑及效率,让用户察觉程序过程是一个平滑的过程。题主前边举的图片修改读取的例子并不是很恰当,既然要后台修改图片又想用户能获取修改后的图片,那这期间的等待过程是一个必须的过程,难不成你还想把不完整的或是错误的数据展现给用户?这种情况,加锁等待是正确的方式,不过也涉及到数据量大小、逻辑处理耗时的问题,实际情况还要复杂得多,网络异常超时、存储空间状况、数据加工等,
在用户交互层,小量数据可加锁等待和超时处理,这应该是可接受的延迟
大量数据及复杂逻辑的后台处理,可采用通知更新的方式,后台处理完了再通知交互层调用更新
做到这两点,就应该有不错的体验了。
加锁,程序写入时用户不许读取
设置一份缓存数据,然后定时更新当前修改的数据。
就你题目中的问题,想要及时读到更改的信息,就必须把同步操作优化到最小的范围,在绝大部分情况下可以线程并行,在真正的读写时候才会有同步操作
没太看懂,直接更新用户所看到的部分不就行了吗?你的意思是不是更改了信息,用户没有重新加载页面,所以看不到?如果是这样的话,完全可以在修改信息完成后刷新UI,同步直接在操作完成后刷新,异步在callback里刷新。如果是文件,则重新载入。