英文:
How can I use Riak connection pool with Beego Framework
问题
我正在使用Beego和Riak开发后端。我正在寻找一种方法来保持Riak连接池的活动状态，但是除了与SQL相关的文档外，我找不到其他任何信息。
我对Go语言还很陌生（两天前开始学习），我不知道连接池是否是正确的选择。据我了解，每个Go应用程序都应该设计成可以独立工作，以便轻松扩展。如果是这样的话，也许单个连接会是更好的选择。如果是这种情况，我应该使用什么最佳实践呢？
如果我的问题看起来很新手，我提前向你道歉，因为在Django背景下，我不习惯管理数据库连接。
我正在使用的Riak连接器是"github.com/tpjg/goriakpbc"。
英文:
I'm developing a back-end using Beego and Riak. I'm searching for a way to keep the riak connection pool alive but I cannot find nothing in documentation besides SQL related.
I'm really freshman to the Go language (started learning 2 days ago) and I don't know if connection pool is the write choice. As I understand, each Go app should be designed to work independently allowing easy scalability. If this is write maybe a single connection should be better choice. If this is the case, what is the best practice I can use?
I'm sorry in advance if my question seems noobie, but, with my Django background, I'm not used to manage db connections.
The riak connector I'm using is "github.com/tpjg/goriakpbc"
答案1
得分: 2
是否使用连接池更多地取决于您的使用模式和工作负载，而不仅仅是您选择的数据存储或客户端库。
每次建立TCP连接时，都会进行三次握手：
- 客户端 --
syn--> 服务器 - 客户端 <--
syn-ack-- 服务器 - 客户端 --
ack--> 服务器
这通常需要很少的时间和网络带宽，并在每台机器上的conntrack表中创建一个条目。如果您的应用程序对每个请求都打开一个新连接，并且每秒发送许多千个请求，您可能会溢出conntrack表，阻塞新连接直到一些先前的连接关闭；或者创建连接的开销可能限制您每秒可以处理的请求数量。
如果您决定使用连接池并使用短生命周期的进程来处理单个请求，然后终止，您将需要一种方法来单独创建和维护连接，使其与请求进程分开，并且一种方法让请求进程使用连接池中的连接发送请求和接收响应。
您可能会发现，如果您的应用程序没有生成足够的流量，那么设计应用程序以使用连接池所需的工作量可能超过使用连接池所带来的任何好处。
这没有正确或错误的答案，这将严重依赖于您的用例、请求量和网络能力。
英文:
Whether or not to use a connection pool depends more on your usage pattern and workload that your choice of data store or client library.
Each time a TCP connection is established, there is a three-way handshake:
- client --
syn--> server - client <--
syn-ack-- server - client --
ack--> server
This usually takes a very small amount of time and network bandwith, and creates an entry in the conntrack table on each machine. If your application opens a new connection to the server for every request and will be sending many thousands of requests per second, you may overflow the conntrack table, blocking new connections until some previous connections close; or the overhead traffic of creating connections could limit how many requests you can handle per second.
If you decide to use a pool and use short-lived processes that handle a single request and then terminate, you will need some method of creating and maintaining connections separately from the request processes, and a method for the request processes to send requests and receive responses using a connection from the pool.
You may find that if your application does not generate a sufficient volume of traffic, the effort required to design your application to use a connection pool outweighs any benefits gained by using a pool.
There is not right or wrong answer, this is going to heavily depend on your use case, request volume, and network capabilities.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论