【6.0.6】关于活字格连接redis问题，redis有哪些odbc驱动可用？

目前因为没有odbc驱动无法让活字格链接到redis上，请问7.0是用什么方法链接redis的？
我自己想链接redis使用要怎么操作？哪里有可以用的odbc驱动？

感谢支持~

开源的没有找到,只找到一个收费的odbc驱动,安装上 验证可以正常连接redis库也能操作
https://redislabs.com/redis-ente ... bc-jdbc-connectors/

感谢您对活字格的支持。
后面有问题，欢迎继续发帖交流

收到 谢谢,我先研究

有时候我在想,活字格可以组织一些聊天会,让一些资深的用户,坐一起聊天讨论一下,畅想一下自己想要做的东西,不一定是100%的解决方案,但是可以讨论方向,沟通想法,头脑风暴一下说不准能在沟通的过程相互都有收获.

现在活字格 已经基本补齐了前后端分离开发模式的相关能力能够满足前后端分离的开发需求,也开放了用户表,前端上也支持流式布局,前端框架也相应优化了速度,整体看下来我需要的都有了.

还缺的是高性能解决方案,我们用传统的代码开发思维想看看能不能直接引入redis来解决,同时我们开发的系统接下来要进行微服务化的重构,以便更好的配合公司业务变动需求.

这里涉及到整个架构的设计,是用纯代码,还是用低代码来作为这个微服务的核心,怎样才是人员,资金投入最少效率最高的.

活字格用了几年了,从最开始的4.0时代没有模块化,到5.0开始做模块化,到6.0服务器端的前后端分离,程序开发的设计方式也慢慢的从单体非异步的程序设计,慢慢的变成多模块异步调取的设计方式,最后再用纯代码的时候也引入了任务队列的设计方式.

为什么每次有新的功能后我会冒出一些新的想法,这主要是我也是一边做一边在学习的过程导致,很多时候我也很困惑希望能有比我高一维度的人能更早的告诉我你应该这样做才对,但是很不巧我没有遇到,所以需求才会这样一点点的蹦出来,需要先上了这个山头才看到下一座山.

为什么重新评估 活字格+redis 而不是继续投入到纯代码上?
原因是 纯代码开发真的慢,人员要求也高,而且前端,后端技术栈还分开,需要更多的投入,而且有经验的人才不好找成本高.
想探索更低成本的开发模式,更快的开发效率,同时满足高性能开发要求.

6.0版本 服务器端命令 缺少一些核心能力,导致我们想以活字格的服务器端名利作为核心 来架构我们公司的平台系统无法满足100%的技术需求.

导致我们开始用纯代码开发了一套快速的api开发平台,在这套平台里面我们需要拓展很多的东西,甚至包括商城在里面,所以架构实现过程引入了redis来解决高并发需求,也通过redis实现任务队列能力,整个程序设计上可以更好的满足高并发,松耦合,微服务化的需求.

而近期活字格发布了7.0 版本,根据新发布的功能,基本补齐80%之前评估认为缺少无法满足作为平台底层开发平台使用的能力,目前好剩余这一块高并发,高性能任务队列的能力,我们想通过直接引入redis来解决,所以在测试这一块引入活字格后能达到什么样的效果.性能能不能达到预期的要求.

这个我们短时间内不会支持的
（目前对数据库的支持，就近的在考虑PGSQL，还有就是国产数据库）

你为啥要连接这个呢？能不能分享一下您的故事

是否考虑  直接支持redis而不用通过odbc连接?