Etherchannel (as mentioned by Leo) takes multiple links (older devices up to 8 links, some of the later devices can do more) and logically treats them as one link.
Flows are not split across links, so the most bandwidth a single flow can obtain is the bandwidth of one link. What you do obtain, is more aggregate bandwidth to be used by multiple flows. So, for example, in the case of two flows, each might obtain the full bandwidth of a single link.
Unfortunately, the "gotcha" with Etherchannel, it doesn't do any kind of dynamic load balancing. So, for example, again in the case of two flows, both might be directed to the same link, while the other(s) are totally unused.
Link usage is determined by traffic attributes and the hashing algorithm being used. Worse case, all flows are directed to one link. Best case, flows are, somewhat, evenly distributed across links. (During short time intervals, you'll often see some links carrying more traffic than other links, but overtime, ideally, link loading is equally distributed.)
In the older forms of Etherchannel, link load distribution works best with powers of two number of links, i.e. 2, 4 and 8. The later devices might offer a better load distribution with non-powers of two number of links.
On average, dual links (again, best cast) might only average about one and a half times the bandwidth of a single link. (Why? Because a second flow might be directed to the same flow as the first flow. I.e. you have a 50/50 change it will get the second link.)
Etherchannel, besides providing more aggregate bandwidth, is often ideal to improve redundancy. Why? Because the multiple links generally don't need to be on the same line card, stack member, or VSS member. I.e. this avoids some single points of failure.
PS:
BTW, if you really want/need a 20 Gbps data rate (for single flow), you need a single link/port that provides 20 Gbps or better.
